On Fri, Jul 25, 2014 at 5:12 PM, Ryan Hiebert wrote:
> I agree that learning to deal with git is probably one of the best things
> we can encourage a new user to do. To that extent, I agree with your
> sentiment, and if we can encourage more usage of git, I’m all for it. We
> are the entry point
Actually, managed won't work, because that just affects if stuff gets put
into migration files, IIRC - even if you change it it won't affect
migrations.
The main problem is that whatever you do, Django is going to mark the
migration as applied if you have sessions set to a non-db store and then
wh
Managed might be the ticket then. I don't think it's too surprising to the
user who configures a cache or file session backend that no database table
is created. I think that's slightly less surprising than the status quo --
they configured a file session backend and when they run migrate they
noti
Yeah, but if you change the value of the routers during a project's
lifetime it's up to you to fix the resulting issues (same as if you switch
AUTH_USER_MODEL - you _cannot_ change this after project start without
serious pain).
If you're happy saying the same thing about sessions, then go and tie
Isn't that essentially what's happening by respecting router.allow_migrate?
Determining at runtime via a setting (DATABASE_ROUTERS) whether to apply
migrations. From the perspective of a user, providing a custom database
router makes sense for applications they don't control, but from the
perspecti
> On Jul 25, 2014, at 2:22 PM, Andre Terra wrote:
> On Fri, Jul 25, 2014 at 12:17 PM, Ryan Hiebert wrote:
> > I see two benefits. One is that users who are interested in testing
> > aren't necessarily going to think to go to github; they're likely to
> > look for the most recent release and use t
I don't think there's a way you can do this with migrations. You're not
supposed to be able to change them at runtime based on settings; that was
the cause of most of our bugs with swappable models.
Andrew
On Fri, Jul 25, 2014 at 12:48 PM, Nick Sandford
wrote:
> Ahh ok, that makes sense -- I g
Ahh ok, that makes sense -- I guess there's no difference between
overriding get_model(s) and manually deleting the model out of the source
to the migrations.
I can't think of any decent way to use router.allow_migrate in sessions
other than monkey patching it to do what I want. Any suggestions?
On Fri, Jul 25, 2014 at 12:17 PM, Ryan Hiebert wrote:
> > I see two benefits. One is that users who are interested in testing
> > aren't necessarily going to think to go to github; they're likely to
> > look for the most recent release and use that (on the other hand, if
> > they see a beta 4 and
Migrations instantiate their own copies of AppConfig and Apps and run from
those, so you won't be able to affect them by overriding methods. If you
want to exclude models from migrations use router.allow_migrate.
Andrew
On Fri, Jul 25, 2014 at 11:59 AM, Nick Sandford
wrote:
> I was just workin
I was just working on #22986 and it seems that if the
AppConfig.get_model(s) methods are overridden, migrations for models that
are excluded are still run.
Is this a known issue? Am I abusing get_model(s) or should I file a ticket
for this?
Cheers,
Nick
https://code.djangoproject.com/ticket/2298
Here is the ticket for putting pre-releases on PyPI.
https://code.djangoproject.com/ticket/21108
We tried it for 1.7 alpha but it didn't work.
On Friday, July 25, 2014 11:21:21 AM UTC-4, Carl Meyer wrote:
>
> On 07/25/2014 09:17 AM, Ryan Hiebert wrote:
> > On a somewhat-related tangent, I seem
+1.
Aymeric, I can't thank you enough for taking this on and running with it.
Jacob
On Fri, Jul 25, 2014 at 7:20 AM, Chris Foresman wrote:
> As a non-core community member, I welcome a streamlined way for new
> potential coders to contribute.
>
>
> On Thursday, July 24, 2014 7:02:16 AM UTC-5,
On 07/25/2014 09:17 AM, Ryan Hiebert wrote:
> On a somewhat-related tangent, I seem to recall there being a good
> reason for not releasing pre-release versions on PyPI, but I’m having
> trouble finding the discussions that document that reason. Anybody
> care to enlighten me, or give me a link?
U
> On Jul 25, 2014, at 10:06 AM, Ian Kelly wrote:
>
> On Fri, Jul 25, 2014 at 7:12 AM, Ryan Hiebert wrote:
>>
>>> On Jul 25, 2014, at 12:22 AM, Ian Kelly wrote:
>>>
>>> It seems to me that a new release would be useful to have for the
>>> reasons given, but it should be called what it is: a b
On Fri, Jul 25, 2014 at 7:12 AM, Ryan Hiebert wrote:
>
>> On Jul 25, 2014, at 12:22 AM, Ian Kelly wrote:
>>
>> It seems to me that a new release would be useful to have for the
>> reasons given, but it should be called what it is: a beta version, not
>> an RC.
>>
> I agree, but I don’t think that
Hi Brian,
On Fri, 25 Jul 2014, Brian May wrote:
> I can't help but think this might be unrealistic (?). Changes required for
> new versions of Django often break compatibility with old versions, and
> 1.4.5 is really old now. Just because many packages don't have versioned
> dependencies on Django
As a non-core community member, I welcome a streamlined way for new
potential coders to contribute.
On Thursday, July 24, 2014 7:02:16 AM UTC-5, Russell Keith-Magee wrote:
>
> Hi Aymeric.
>
> A big +1 from me. Thanks for all your work drafting these modifications.
>
> Russ %-)
>
> On Wed, Jul 23,
> On Jul 25, 2014, at 12:22 AM, Ian Kelly wrote:
>
> It seems to me that a new release would be useful to have for the
> reasons given, but it should be called what it is: a beta version, not
> an RC.
>
I agree, but I don’t think that releasing a beta after an RC makes good sense
either. If th
Hi Andrew,
thanks for your quick answer.
On Thu, 24 Jul 2014, Andrew Godwin wrote:
> There is no way around this; it's unfortunate that the packaging situation
> means that Django will get auto-upgraded as part of a distribution upgrade;
> I'm surprised that Debian hasn't had this with packages
20 matches
Mail list logo
