PIP django version dependency

[Michael Boratko]

When I just ran the command pip install django-cms and ran through the entire setup, I was greeted with many error messages because pip had installed django 1.4. It seems to me that there is no reason not to make the django dependency an equality (django==1.3.1) instead of >=, as it is currently. For this release and for future releases, it seems to make much more sense for the dependencies on pip to limit it to the most recent version of django which is known to work, and not leave it open to errors when django updates to a new unsupported version.

[Martin]

+1

[Jonas Obrist]

Okay so let me explain the logic here:

1: we also support 1.2.7, not just 1.3.1.

2: if we lock it to a specific version, every time Django does a patch (eg 1.3.1->1.3.2) we have to do a release too, that is not something I want to do.

3: What if 1.4 just worked? Everyone would be pissed at us for locking it on 1.3 if 1.4 works perfectly fine.

4: The right solution for this is to specify the versions your project uses in your requirements file.

[Michael Boratko]

That makes sense, thank you for explaining. The only problem is that the website instructions to install Django CMS by just typing "pip install django-cms" do not work, then.

It would be great if pip had a method for supplying multiple bounds on requirements, does anyone know if it does? Something like 1.2.7<=Django<1.4 would be great. Even better would be something like "Django>=1.2.7&&Django<1.4". Anyway, as it stands now, the instructions on the website won't work.

[Andrea Corbellini]

Hello,

I'd like to give you my 2 cents.

On Sat, 2012-03-31 at 08:25 -0700, Michael Boratko wrote:
> That makes sense, thank you for explaining. The only problem is that
> the website instructions to install Django CMS by just typing "pip
> install django-cms" do not work, then.
>
>
> It would be great if pip had a method for supplying multiple bounds on
> requirements, does anyone know if it does? Something like
> 1.2.7<=Django<1.4 would be great. Even better would be something like
> "Django>=1.2.7&&Django<1.4". Anyway, as it stands now, the
> instructions on the website won't work.

PIP (or, better, setuptools) already has this feature. The syntax is:

install_requires=[
...
'django >= 1.2.7, < 1.4',
...
]

However the point #3 that Jonas has pointed out (What if 1.4 just
worked?) remains. And being unable to perform an upgrade that will work
flawless is, in my experience, a very annoying thing.

In my opinion, the best thing django-cms can do to prevent errors
introduced by upgrades is telling people in the documentation to specify
the Django version in the project's setup.py.

[Michael Boratko]

That's great that pip already has this feature. Obviously the current release needs to have this.

I would still advocate for limiting the version to known releases, i.e. before 1.4 was released, still include the <1.4 requirement. My reasoning is this:

 - In practice, how often has a major version upgrade to Django worked flawlessly?

 - Even if it did work flawlessly, new users won't notice the difference and it's better to get them up and running with something

 - Experienced users can still manually force django to upgrade to 1.4 around the <1.4 requirement after it is installed, can't they?

This would protect from the (almost 1 week at this point) downtime for new users to install and get django-cms up and running. What I mean is, for the last week, if a new potential user has gone to the Django CMS site and followed the directions, it would not work. This could have been avoided by putting the <1.4 requirement in beforehand.

[Andrea Corbellini]

On Sat, 2012-03-31 at 11:59 -0400, Michael Boratko wrote:
> That's great that pip already has this feature. Obviously the current
> release needs to have this.
>
>
> I would still advocate for limiting the version to known releases,
> i.e. before 1.4 was released, still include the <1.4 requirement. My
> reasoning is this:
> - In practice, how often has a major version upgrade to Django worked
> flawlessly?
> - Even if it did work flawlessly, new users won't notice the
> difference and it's better to get them up and running with something
> - Experienced users can still manually force django to upgrade to 1.4
> around the <1.4 requirement after it is installed, can't they?

Yes, they can with:

pip install django-cms --no-dependencies

(Assuming that all the dependencies were installed previously)

It should be noted that this is a "manual step": with just your
project's setup.py, you can't tell setuptools to ignore django-cms
install requirements.

[Jonas Obrist]

Again, what if 1.4 worked? People would still complain about the upper bound...

[Martin]

I guess updating the docs is probably the easiest and most flexible route that should make everyone happy.

[Manolis Stamatogiannakis]

What has the history been so far for minor django upgrades? Have there been problems at the time each minor django version was released? If yes, then limiting the django version is the way to go.

Whatever the choice for the dependency is, in the end there will always be some complaints. Given this, IMHO the "proper" django dependency should be chosen so as to make life easier for the majority of django-cms users.

I doubt that those who truly need to have e.g. django 1.4 (i.e. need some of the features - not just for the sake of upgrading) just a week after its release are anywhere close to a majority.
And most likely this minority also knows pretty well what they are doing, so they can figure how to upgrade despite what the pip dependency says.

Now, django pushes out minor releases every ~9 months (https://docs.djangoproject.com/en/dev/internals/release-process/#minor-releases). Also having a django-cms maintenance release every 9 months does not sound that terrible.

If nothing needs to be fixed only the django dependency will be bumped-up and the maintenance release will be out really quick. But if changes have to be made, in the meantime new django-cms installations and upgrades to existing sites will not break by accident.

Just my 2c.

Manolis

2012/3/31 Jonas Obrist <ojii...@gmail.com>

[Michael Boratko]

+1 for Manolis' reply.

As for minor version releases, however, the API rarely changes and so it wouldn't break Django CMS (correct me if I'm wrong). Therefore I think that limiting it using < #, where # is the next major release number, would allow for automatic security related upgrades (i.e. the minor releases of Django) while prohibiting the current situation (turning away a lot of new users). Then, as Manolis said, the more experienced users who want Django 1.4 within a week after its release can easily handle overriding the pip dependency, if it even works.

[Andrea Corbellini]

I would like to point out something that hasn't been already stated.
New Django releases can break anything, not just django-cms. This
means that even if django-cms could work with the upcoming release of
Django, nobody can ensure that also the user's application will work.
Therefore, whichever solution you'll choose, recommending the use of
'< 1.x' for the user's setup.py in the documentation/tutorial is
always a good thing to do.

--
Ubuntu member
http://www.ubuntu.com/