#django

FunkyBob: printline yes

so there's no error... and you've restarted the service?

FunkyBob: The service restarts itself, no? It certainly looks like it in the konsole output. Also, if I remove the argument to the tag (3), I get an error: get_upcoming_events did not receive value(s) for the argument(s): 'count'

OK, so the template is just compiled and checked, but the template tag itself is never called

s/compiled/parsed

and basea.html has a {% block content %} ...

people using uwsgi, do you install thisin your virtualenv our system ?

FunkyBob: the extended "base.html" has a {% block content %}{% endblock %} yes

fission6: Either works for me. I tend to default to the distro package if it's new enough, and only install it in the virtualenv if I need a newer version.

FunkyBob: Perhaps I should try with an inclusion tag, just for good measure

alrighty

mattmcc: having it outside the virtualenv is making it easy for upstart scripts

fission6: I prefer to pip install uwsgi... then I don't have to worry about plugins [default build includes all the plugins I use]

also for some time the distro versions were too old

well i was asking do you install uwsgi system wide or in a venv

since I use emperor, system wide

Alright. I need another pair of eyes. I had both of these forms loading last night, and now it's giving me a ManagementForm error when I get to rendering the inlineformset. https://dpaste.de/jVyT here is the template, and here is the view https://dpaste.de/3SEN

shouldn't it be {{ lines_formset.management_form }} ?

look at the rendered page, see if anything actually renders from that

But it is {{ lines_formset.management_form }} ... isn't it? Honestly at this point you could tell me I have the mark of the devil in my code and I'd probably believe it.

bcSquared: you should remove {{ form.management_form }}

my guess is you need to pass None instead of request.POST when you want an unbound formset to render

fuck. doing request.POST or None actually worked.

but why.

by passing anything other than None as the first argument, the formset becomes "bound", and validates all the data

and now back to my problem from last night. at least i feel like i got back to square one. lol

knbk, ah. cool.

for shits and grins - https://docs.djangoproject.com/en/1.9/topics/fo... does this article not assume that an author_id is being passed to the view? Suggesting that the Author object already exists in which the Books are being created for?

any ideas why if i daemonize uwsgi in an upstart script i can do sudo service uwsgi start, but not stop, i get stop: Unknown instance:

fission6: don't daemonize it

apparently not

fission6: otherwise upstart can't keep track of it

yea but why!

because it detaches from its controlling process

that's what daemonising is

and generally, it's someting most programs have no business being able to do

bcSquared: it does assume that

knbk, thank you. I just wanted to make sure I wasn't crazy. So how in the hell do you create a formset for children models when the parent model hasn't been created yet?

save the parent first

and stop reading SO

I thought it was worth a shot. I wanted to mainly prove to myself that all I was going to get was an RTFM answer.

consider -- admin quite happily lets you create a model and its inlines in one view

FunkyBob, how do you do that if they are created at the same time? Should I just bite the bullet and break it in to two steps?

bcSquared: save the parent... save the inline...

I can't be much more specific as I almost never use formsets

RqfFormSet(..., instance=form.instance)

then save the form before you save the formset

hrmm. form.instance.

holy shit.

I just jumped out of my chair. That actually worked, knbk.

haha glad I could help

I wish formsets had access to the instance they were working with as opposed to just the parent.

don't the forms in the formset have that?

Maybe?

I mean, clearly something *somewhere* knows about the instances.

Yeah, for form in formset: form.instance should work just the same.

Yeah, you know, I said that thing and now I don't actually know what I was thinking.

:)

My thought process was really "I wish I could change my fieldsets in a inlinemodeladmin based on the instance", and I don't think you can do that by going form -> formset -> inlinemodeladmin, because you can't define fieldsets on a form in the same way.

it's a bad idea to change AUTH_USER_MODEL midway through a project isn't it?

At least, not last time I checked. Though I guess I could go crib whatever methods render fieldsets right now and put them in my own form.

shangxiao: Not *bad* necessarily, so long as you properly port all your data into the new model before switching.

it's bad due to the fk switching

You can port that, too.

That doesn't make it bad, just nontrivial.

shangxiao: porting to a new user model is far from simple, see #25313

And then write a custom migration to remap your indexes, constraints, etc.

New nullable FK, copy values, remove old FK, rename new FK, remove null, yadda.

yep the old 3-stage-migration-done-right routine

It's a good reason to start a project with a custom user model if you think there's the slightest chance you'll need one eventually.

knbk: thanks for that link, that's the discussion i was looking for

I think I'd want to subclass something around InlineAdminFormSet in order to modify fieldsets per instance.

Anyone ever done that before? I'm pretty spent right now as far as Django spelunking goes.

why would you need to migrate user systems? I thought that (in theory) it was supposed to be fairly straight forward to just extend the User model.

or I hope it is. >_>