It is an error to refer to an extra that has not been declared. In your case you would get an error if some version of Django >= 1.4 that did not declare the extra was installed.
pip install pip[pop] UnknownExtra: pip 6.0.6 has no such extra feature 'pop' One thing you could do with the current technology is to have two empty mezzanine-django-old and mezzanine-django-new packages that just depend on a third mezzanine package, the appropriate version of django, and the appropriate comments add on. On Thu, Jan 22, 2015 at 1:18 AM, Alexander Hill <a...@hill.net.au> wrote: > Hi Nick, > > Just thinking some more about the scenario where Django defines a "comments" > extra. > > Say in our setup.py we have install_requires=['django[comments] >= 1.4']. > What happens when this setup.py is run with Django 1.4 already installed? Is > the (missing) extra just ignored, or will Django be upgraded to a version > which declares the extra? > > (anyone following along, please see my response to Nick below - forgot to > reply all) > > Cheers > Alex > > On Thu, Jan 22, 2015 at 2:04 PM, Alexander Hill <a...@hill.net.au> wrote: >> >> Thanks for your feedback Nick. >> >> Just checking my understanding: say default extras existed and we'd >> implemented them as described, and I'm a Mezzanine user running Django 1.4. >> I see a new version has been released, don't read the release notes >> thoroughly, and run pip install --upgrade mezzanine as usual instead of >> specifying [-comments]. This would still install django-contrib-comments and >> upgrade Django in the process, is that right? >> >> Seems like the cleanest way to do this would be for Django itself to >> define a "comments" extra, requiring django-contrib-comments, in Django >> 1.8's setup.py. >> >> Cheers, >> Alex >> >> On Thu, Jan 22, 2015 at 1:29 PM, Nick Coghlan <ncogh...@gmail.com> wrote: >>> >>> On 21 January 2015 at 16:13, Alexander Hill <a...@hill.net.au> wrote: >>> > Hi all, >>> > >>> > I have run into a bit of a head-scratcher. >>> > >>> > Prior to the upcoming version 1.8, Django included a comments app at >>> > django.contrib.comments. As of 1.8, the app has been broken out into an >>> > independent package, django-contrib-comments [1]. >>> > django-contrib-comments >>> > requires Django >= 1.5. >>> > >>> > The project I'm working on (Mezzanine) requires Django comments. I want >>> > Mezzanine to support Django 1.4 through to 1.8, so I need >>> > django-contrib-comments. But because it requires Django >= 1.5, when >>> > it's in >>> > my dependencies Django gets automatically upgraded if version 1.4 is >>> > installed, so the Mezzanine test suite isn't actually run under 1.4 >>> > [2]. >>> > >>> > Is there some way to only depend on django-contrib-comments if a >>> > minimum >>> > version of Django is installed? Or any other way around this problem? >>> > Any >>> > advice greatly appreciated! >>> >>> The closest I can think of is to make the comments support an extra, >>> so you'd need to specify "mezzanine[comments]" to get >>> django-contrib-comments on 1.5+. That's unlikely to be acceptable in >>> this case though, since existing dependencies on mezzanine would fail >>> to install the comments support. >>> >>> While it won't help you right now, I did have an idea for a possible >>> way to deal with this in PEP 426: provide a way to specify a set of >>> "default extras" for a project. Those dependencies would still be >>> installed by default, but you'd have an easy way to turn them off if >>> you didn't want them. >>> >>> Then, in this case, you'd be able to run the Django 1.4 tests using >>> "mezzanine[-comments]" rather than a default install to avoid >>> attempting to install django-contrib-comments. >>> >>> Filed as: https://github.com/pypa/interoperability-peps/issues/18 >>> >>> Regards, >>> Nick. >>> >>> -- >>> Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia >> >> > > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig > _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
