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 <[email protected]> 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 - [email protected]
> https://mail.python.org/mailman/listinfo/distutils-sig
>
_______________________________________________
Distutils-SIG maillist - [email protected]
https://mail.python.org/mailman/listinfo/distutils-sig
