Versioned trove classifiers for Django
Following up on some IRC discussion with other folks:
There is precedent (Plone) for PyPI trove classifiers corresponding to particular versions of a framework. So I'd like to get feedback on the idea of expanding that, particularly in the case of Django.
The rationale here is that the ecosystem of Django-related packages is quite large, but -- as I know all too well from a project I'm working on literally at this moment -- it can be difficult to ensure that all of one's dependencies are compatible with the version of Django one happens to be using.
Adding trove classifier support at the level of individual versions of Django would, I think, greatly simplify this: tools could easily analyze which packages are compatible with an end user's chosen version, there'd be far less manual guesswork, etc., and the rate of creation of new classifiers would be relatively low (we tend to have one X.Y release/year or thereabouts, and that's the level of granularity needed).
Assuming there's consensus around the idea of doing this, what would be the correct procedure for getting such classifiers set up and maintained?
I complete support James. This trove classifier is something that could be pretty easily plugged right into Django Packages and the rest of the Django ecosystem.
--Daniel Greenfeld
On Sun, Mar 29, 2015 at 9:49 PM, James Bennett ubernostrum@gmail.com wrote:
Following up on some IRC discussion with other folks:
There is precedent (Plone) for PyPI trove classifiers corresponding to particular versions of a framework. So I'd like to get feedback on the idea of expanding that, particularly in the case of Django.
The rationale here is that the ecosystem of Django-related packages is quite large, but -- as I know all too well from a project I'm working on literally at this moment -- it can be difficult to ensure that all of one's dependencies are compatible with the version of Django one happens to be using.
Adding trove classifier support at the level of individual versions of Django would, I think, greatly simplify this: tools could easily analyze which packages are compatible with an end user's chosen version, there'd be far less manual guesswork, etc., and the rate of creation of new classifiers would be relatively low (we tend to have one X.Y release/year or thereabouts, and that's the level of granularity needed).
Assuming there's consensus around the idea of doing this, what would be the correct procedure for getting such classifiers set up and maintained?
Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Hi James,
I tend to just require that there already exists a number of packages that would use the classifier. Sounds like that's the case?
Richard
On Mon, 30 Mar 2015 at 15:50 James Bennett ubernostrum@gmail.com wrote:
Following up on some IRC discussion with other folks:
There is precedent (Plone) for PyPI trove classifiers corresponding to particular versions of a framework. So I'd like to get feedback on the idea of expanding that, particularly in the case of Django.
The rationale here is that the ecosystem of Django-related packages is quite large, but -- as I know all too well from a project I'm working on literally at this moment -- it can be difficult to ensure that all of one's dependencies are compatible with the version of Django one happens to be using.
Adding trove classifier support at the level of individual versions of Django would, I think, greatly simplify this: tools could easily analyze which packages are compatible with an end user's chosen version, there'd be far less manual guesswork, etc., and the rate of creation of new classifiers would be relatively low (we tend to have one X.Y release/year or thereabouts, and that's the level of granularity needed).
Assuming there's consensus around the idea of doing this, what would be the correct procedure for getting such classifiers set up and maintained? _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
On Sun, Mar 29, 2015 at 11:58 PM, Richard Jones richard@python.org wrote:
I tend to just require that there already exists a number of packages that would use the classifier. Sounds like that's the case?
I don't have a count handy, but yes, I suspect the number of packages which currently use the "Framwork :: Django" classifier is significant, and that with documentation we could easily get most of them to start using a versioned classifier :)
Richard,
If you look at https://www.djangopackages.com you'll see that 631 packages are Python 3 compatible out of 2714 listed. This number has been growing steadily, as package maintainers have learned that they can get listed there by utilizing the trove classifier system. It wasn't hard for us to get that started.
Since compatibility for packages across Django version is a big deal, having this on PyPI and downstream tools like Django Packages will be an immense help to the Django ecosystem.
--Danny
On Sun, Mar 29, 2015 at 9:58 PM, Richard Jones richard@python.org wrote:
Hi James,
I tend to just require that there already exists a number of packages that would use the classifier. Sounds like that's the case?
RichardOn Mon, 30 Mar 2015 at 15:50 James Bennett ubernostrum@gmail.com wrote:
Following up on some IRC discussion with other folks:
There is precedent (Plone) for PyPI trove classifiers corresponding to particular versions of a framework. So I'd like to get feedback on the idea of expanding that, particularly in the case of Django.
The rationale here is that the ecosystem of Django-related packages is quite large, but -- as I know all too well from a project I'm working on literally at this moment -- it can be difficult to ensure that all of one's dependencies are compatible with the version of Django one happens to be using.
Adding trove classifier support at the level of individual versions of Django would, I think, greatly simplify this: tools could easily analyze which packages are compatible with an end user's chosen version, there'd be far less manual guesswork, etc., and the rate of creation of new classifiers would be relatively low (we tend to have one X.Y release/year or thereabouts, and that's the level of granularity needed).
Assuming there's consensus around the idea of doing this, what would be the correct procedure for getting such classifiers set up and maintained? _______________________________________________ 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
OK, so what's the set of versions you'd like to see?
On Mon, 30 Mar 2015 at 16:03 Daniel Greenfeld pydanny@gmail.com wrote:
Richard,
If you look at https://www.djangopackages.com you'll see that 631 packages are Python 3 compatible out of 2714 listed. This number has been growing steadily, as package maintainers have learned that they can get listed there by utilizing the trove classifier system. It wasn't hard for us to get that started.
Since compatibility for packages across Django version is a big deal, having this on PyPI and downstream tools like Django Packages will be an immense help to the Django ecosystem.
--Danny
On Sun, Mar 29, 2015 at 9:58 PM, Richard Jones richard@python.org wrote:
Hi James,
I tend to just require that there already exists a number of packages
that
would use the classifier. Sounds like that's the case?
RichardOn Mon, 30 Mar 2015 at 15:50 James Bennett ubernostrum@gmail.com
wrote:
Following up on some IRC discussion with other folks:
There is precedent (Plone) for PyPI trove classifiers corresponding to particular versions of a framework. So I'd like to get feedback on the
idea
of expanding that, particularly in the case of Django.
The rationale here is that the ecosystem of Django-related packages is quite large, but -- as I know all too well from a project I'm working on literally at this moment -- it can be difficult to ensure that all of
one's
dependencies are compatible with the version of Django one happens to be using.
Adding trove classifier support at the level of individual versions of Django would, I think, greatly simplify this: tools could easily analyze which packages are compatible with an end user's chosen version,
there'd be
far less manual guesswork, etc., and the rate of creation of new
classifiers
would be relatively low (we tend to have one X.Y release/year or thereabouts, and that's the level of granularity needed).
Assuming there's consensus around the idea of doing this, what would be the correct procedure for getting such classifiers set up and
maintained?
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
-- 'Knowledge is Power' Daniel Greenfeld Principal at Cartwheel Web; co-author of Two Scoops of Django twoscoopspress.org | pydanny.com
On Mon, Mar 30, 2015 at 12:04 AM, Richard Jones richard@python.org wrote:
OK, so what's the set of versions you'd like to see?
The current upstream-supported version set is Django 1.4, Django 1.6, Django 1.7. Soon 1.6 will drop out and be replaced by 1.8, but that's just because we're coming up on a release.
Since a lot of sites are still migrating from 1.5, shouldn't we add that version to the mix?
1.4 1.5 1.6 1.7
--Danny
On Sun, Mar 29, 2015 at 10:06 PM, James Bennett ubernostrum@gmail.com wrote:
On Mon, Mar 30, 2015 at 12:04 AM, Richard Jones richard@python.org wrote:
OK, so what's the set of versions you'd like to see?
The current upstream-supported version set is Django 1.4, Django 1.6, Django 1.7. Soon 1.6 will drop out and be replaced by 1.8, but that's just because we're coming up on a release.
Added!
Framework :: Django :: 1.4 Framework :: Django :: 1.5 Framework :: Django :: 1.6 Framework :: Django :: 1.7 Framework :: Django :: 1.8
On Mon, 30 Mar 2015 at 16:09 James Bennett ubernostrum@gmail.com wrote:
I would be OK with including 1.5 just for completeness' sake.
On 3/30/15 1:13 AM, Richard Jones wrote:
Added!
Framework :: Django :: 1.4 Framework :: Django :: 1.5 Framework :: Django :: 1.6 Framework :: Django :: 1.7 Framework :: Django :: 1.8
Great! In Plone's case, we also added every foreseeable future version, which it appears you have already done. Tha gives folks the ability to cut new releases of add-ons against beta and rc versions of Django, which is awesome.
On Mon, 30 Mar 2015 at 16:09 James Bennett <ubernostrum@gmail.com mailto:ubernostrum@gmail.com> wrote:
I would be OK with including 1.5 just for completeness' sake.
Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Reviving this old thread because today is Django 1.9's release date and I'm unsure of the process for keeping up with new-released versions in trove classifiers. Do we need to manually poke someone each time (as with today, when "Framework :: Django :: 1.9" becomes a thing), or is there a way to automate it?
At the moment it's a manual poke, but I have done this thing right now.
On 2 December 2015 at 10:46, James Bennett ubernostrum@gmail.com wrote:
Reviving this old thread because today is Django 1.9's release date and I'm unsure of the process for keeping up with new-released versions in trove classifiers. Do we need to manually poke someone each time (as with today, when "Framework :: Django :: 1.9" becomes a thing), or is there a way to automate it?
Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Could you add Plone 5.1 too? It may still take half a year or more before we release this, but we are starting to think about what we want to put in there. So this one:
Framework :: Plone :: 5.1
Thanks,
Maurits
Op 02/12/15 om 01:54 schreef Richard Jones:
At the moment it's a manual poke, but I have done this thing right now.
On 2 December 2015 at 10:46, James Bennett <ubernostrum@gmail.com mailto:ubernostrum@gmail.com> wrote:
Reviving this old thread because today is Django 1.9's release date and I'm unsure of the process for keeping up with new-released versions in trove classifiers. Do we need to manually poke someone each time (as with today, when "Framework :: Django :: 1.9" becomes a thing), or is there a way to automate it? _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org <mailto: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
I prefer not to add classifiers unless they're actually going to be used. Half a year could turn into a year :-)
On 4 December 2015 at 08:22, Maurits van Rees m.van.rees@zestsoftware.nl wrote:
Could you add Plone 5.1 too? It may still take half a year or more before we release this, but we are starting to think about what we want to put in there. So this one:
Framework :: Plone :: 5.1
Thanks,
Maurits
Op 02/12/15 om 01:54 schreef Richard Jones:
At the moment it's a manual poke, but I have done this thing right now.
On 2 December 2015 at 10:46, James Bennett <ubernostrum@gmail.com mailto:ubernostrum@gmail.com> wrote:
Reviving this old thread because today is Django 1.9's release date and I'm unsure of the process for keeping up with new-released versions in trove classifiers. Do we need to manually poke someone each time (as with today, when "Framework :: Django :: 1.9" becomes a thing), or is there a way to automate it? _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org <mailto: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
-- Maurits van Rees: http://maurits.vanrees.org/ Zest Software: http://zestsoftware.nl
Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Fair enough. :-)
See you in six or more months. ;-)
Maurits
Op 04/12/15 om 00:53 schreef Richard Jones:
I prefer not to add classifiers unless they're actually going to be used. Half a year could turn into a year :-)
On 4 December 2015 at 08:22, Maurits van Rees <m.van.rees@zestsoftware.nl mailto:m.van.rees@zestsoftware.nl> wrote:
Could you add Plone 5.1 too? It may still take half a year or more before we release this, but we are starting to think about what we want to put in there. So this one: Framework :: Plone :: 5.1
Could we get 'Framework :: Django :: 1.10' please? Django 1.10 has been out for a while :)
On Fri, Dec 4, 2015 at 12:59 AM, Maurits van Rees < m.van.rees@zestsoftware.nl> wrote:
Fair enough. :-)
See you in six or more months. ;-)
Maurits
Op 04/12/15 om 00:53 schreef Richard Jones:
I prefer not to add classifiers unless they're actually going to be used. Half a year could turn into a year :-)
On 4 December 2015 at 08:22, Maurits van Rees <m.van.rees@zestsoftware.nl mailto:m.van.rees@zestsoftware.nl> wrote:
Could you add Plone 5.1 too? It may still take half a year or more before we release this, but we are starting to think about what we want to put in there. So this one: Framework :: Plone :: 5.1-- Maurits van Rees: http://maurits.vanrees.org/ Zest Software: http://zestsoftware.nl
Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Bumping this because Django 1.11 is out, so 'Framework :: Django :: 1.11' would be a useful thing to have.
participants (5)
-
Alex Clark -
Daniel Greenfeld -
James Bennett -
Maurits van Rees -
Richard Jones