[10:46] <scarleo> Hi, I was thinking about trying out Quickly to build a GUI to an already existing python app. Can I import the files to my Quickly project somehow?
[10:49] <scarleo> Or is it as simple as just moving them into the project folder?
[10:58] <noodles775> scarleo: I'd assume you can just move them over, yes (they'll be added next time your code is committed)
[10:59] <scarleo> ok, thanks
[11:05] <jml> So, how do I start up a Django server from within a test?
[11:16] <noodles775> jml: ouch... so this is *not* a test for the django server itself right? It's tests for your backend or similar?
[11:16] <jml> noodles775: it's an integration test.
[11:17] <noodles775> jml: wouldn't you run an integration test against a running server (like the vps), or it's better to be able to do the whole thing locally?
[11:18] <jml> noodles775: I think self-contained is better, yes.
[11:19] <noodles775> jml: yes, if it's possible. So if the django server doesn't depend on other services, you should be able to bootstrap and run it as part of your test setup, using subprocess? (and terminate the process in tearDown?)
[11:19] <noodles775> But it sounds like a lot of work (ie. you'll want a fresh database for the server for each run I assume, so will need to delete that too)
[11:20] <noodles775> s/a lot of work/there will be other factors to consider/
[11:20] <noodles775> (after all, a bit of work once to automate it is pretty priceless :-))
[11:20] <jml> noodles775: is there a way of telling when the service is up? how does it know what port to run on?
[11:21] <jml> how can I find out what port it's running on? (better questions)
[11:21] <noodles775> jml: ./manage.py help runserver will show you how to set the port
[11:21] <noodles775> I assume your setUp will have to ping a url until it gets a 200 response.
[11:21] <jml> Ideally, I'd like to use port 0 & then figure out what it's using.
[11:22]  * noodles775 relocates
[11:22] <jml> what does fabric.api.local do that subprocess.Popen doesn't that I should know about?
[11:30] <jml> and what does django_project/manage actually do?
[11:31] <noodles775> manage.py is just an interface to django's available commands (btw, if it's a project using fabric, you'll want `fab manage:'help runserver'` to get the help I mentioned earlier)
[11:31] <noodles775> s/available commands/available commands in the context of your project/
[11:33] <noodles775> fabric.api.local is, afaik, a helper for when you're running deploy scripts and need to do sosmething locally, as opposed to on the remote server... (i didn't know it could fork a process?)
[11:36] <jml> well, it seems to be running:
[11:36] <jml>     local("virtualenv/bin/python django_project/manage.py {0} {1}".format(
[11:36] <jml>         command, " ".join(args)), capture=False,)
[11:36] <jml> in this project
[11:36] <jml> which *looks* like forking a process
[11:36] <jml> but maybe it's not
[11:37] <noodles775> I don't think it is - if you run `fab manage:runserver` you'll see the server running without forking.
[11:37] <lukasz> jml: it's basically the same as subprocess.Popen blocking call
[11:37] <jml> lukasz: ok, thanks.
[11:38] <jml> so, sometimes in this, manage is called with what looks like a shell command that could be run
[11:38] <jml> e.g.
[11:38] <jml>     manage("celeryd_multi start test -E")
[11:38] <jml> but then that is fed as the first argument to the manage.py call above
[11:39] <jml> which confuses me a little, since https://docs.djangoproject.com/en/1.3/ref/django-admin/ and what noodles775 said earlier implies that manage.py is more for running special provided commands
[11:39] <jml> not shell commands more generally
[11:41] <noodles775> jml: Yes, that would surprise me - I would exect that celeryd_multi *is* a django command provided by some django-celery package.
[11:41] <noodles775> You can find out by doing `fab manage:'help celeryd_multi'`
[11:41] <noodles775> but I'm just guessing - where's the code for this?
[11:42] <jml> noodles775: lp:pkgme-service
[11:42] <noodles775> jml: https://github.com/ask/django-celery
[11:42] <noodles775> It does provide django/manage.py versions of its commands.
[11:43] <jml> noodles775: sorry, what am I looking for on that page?
[11:45] <noodles775> jml: under "Using django-celery" (sorry, the internal link doesn't seem to work)
[11:45] <noodles775> It says: "Everything works the same as described in the Celery User Manual, except you need to invoke the programs through manage.py:"
[11:45] <jml> ahh I see
[11:45] <jml> noodles775: bearing in mind that I'm new to Django, why would someone want to go and do a thing like that?
[11:46] <lukasz> jml: you have just one point of entry for all your django related commands
[11:47] <lukasz> jml: manage.py sets up proper environment for your project
[11:47]  * noodles775 lets lukasz give clearer explanations than his own :)
[11:48] <jml> lukasz: ok. that makes sense.
[12:00] <dpm> mvo, the banners in the SC, are they static images that can be added any time we want to show a new banner, or can they be html as well? (I'm asking out of curiosity e.g. to have image + translatable text)
[12:04] <noodles775> dpm: they're 'exhibits' that can be added at any time via a web interface by anyone with the right perms. They are entered as a small html snippet which can reference (currently) only one image.
[12:05] <dpm> noodles775, ah, thanks for the info :)
[12:20] <jml> well hey, I just found a bug in runserver
[12:20] <jml> if you tell it to run on localhost port 0, it does so (which is great), but then reports that the server is listening on http://localhost:0/
[12:20] <jml> which is a lie
[12:31] <mvo> dpm: its a image with text, the text can be html
[12:33] <dpm> mvo, ah, thanks, that clears things out. I misunderstood what noodles775 was saying in thinking only images could be shown in the html snippets, but now I see he simply meant just one image can be referenced (I assume the background image), but the snippet can contain text
[12:34] <dpm> as well
[12:35] <mvo> yes, thats it
[12:35] <mvo> so the text can be translated
[13:25] <jo-erlend> Is there a place to report things that makes it unnecessarily difficult, complicated or cumbersome to develop or learn how to develop on Ubuntu?
[13:29] <dpm> hi jo-erlend, yes, the mailing list is the best place for such discussions: https://lists.ubuntu.com/mailman/listinfo/ubuntu-app-devel
[13:29] <dpm> or here
[13:29] <jo-erlend> I mean reporting as reporting bugs.
[13:30] <dpm> jo-erlend, I guess it depends on how specific the bug is. Could you give us an example?
[13:33] <jo-erlend> yes. GTK3 applications written in Python cannot reorder ListStores and TreeStores. They have to do that themselves for anything that uses them. I've brought it up on the mailinglist without receiving any replies, and I've reported a bug for PyGObject, but the replies have just been that apps that want to sort, must sort manually. This means that the GTK API doesn't apply to Python GTK apps, which of course is confusing. In an
[13:33] <jo-erlend> y case, this shouldn't be necessary.
[13:34] <jo-erlend> that is an undeniable bug. There are other things, like poor or missing documentation. Or it can be a missing, small feature that would not break anything, but make it easier to do something. I'm sure there are lots of those cases. What I'm after, is a way to collect those types of bugs so we can see what could be done to make things easier -- specially for newbies.
[13:38] <jo-erlend> or perhaps, if there is a launchpad ubuntu-app-devel team, we could simply assign those types of bugs to it?
[13:56] <noodles775> jo-erlend: it'd certainly be excellent to gather all those pain-points somewhere and gradually remove/ease them. Even if it's a wiki page to gather them for the moment? Unless dpm has another option?
[14:00] <dpm> jo-erlend, I agree, perhaps a wiki page with links to the individual bugs would be a start. You can create it as a subpage of https://wiki.ubuntu.com/AppDevelopers
[14:01] <jml> wheee... because celery pickles and unpickles exceptions to report them to the log, any stdlib exceptions that don't upcall properly (e.g. HTTPError) end up with information missing.