Re: [Distutils] Versioned trove classifiers for Django
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 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
Re: [Distutils] Versioned trove classifiers for Django
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
Re: [Distutils] Versioned trove classifiers for Django
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 wrote: > On Mon, Mar 30, 2015 at 12:04 AM, Richard Jones 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. -- 'Knowledge is Power' Daniel Greenfeld Principal at Cartwheel Web; co-author of Two Scoops of Django twoscoopspress.org | pydanny.com ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Versioned trove classifiers for Django
On Mon, Mar 30, 2015 at 12:04 AM, Richard Jones 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. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Versioned trove classifiers for Django
OK, so what's the set of versions you'd like to see? On Mon, 30 Mar 2015 at 16:03 Daniel Greenfeld 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 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? > > > > > > Richard > > > > On Mon, 30 Mar 2015 at 15:50 James Bennett > 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 > ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Versioned trove classifiers for Django
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 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? > > > Richard > > On Mon, 30 Mar 2015 at 15:50 James Bennett 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 ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Versioned trove classifiers for Django
On Sun, Mar 29, 2015 at 11:58 PM, Richard Jones 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 :) ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Versioned trove classifiers for Django
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 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
Re: [Distutils] Versioned trove classifiers for Django
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 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 > -- 'Knowledge is Power' Daniel Greenfeld Principal at Cartwheel Web; co-author of Two Scoops of Django twoscoopspress.org | pydanny.com ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] 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? ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Can I upload a binary wheel to a local devpi on Linux using pip? Do I need setup.py?
On 28 Mar 2015 09:16, "Donald Stufft" wrote: > > Use twine to upload As Donald notes, twine can handle the upload, and devpi (unlike the public PyPI) will happily host Linux wheel files. The main trap to watch out for when using that approach in the current system is that the wheel filenames won't say which Linux distro they were built against, so you may get cryptic runtime errors if they escape the intended environments. Cheers, Nick. > > > > On Mar 27, 2015, at 7:11 PM, Dan Stromberg wrote: > > > > Is it possible to use "pip wheel" to upload a binary wheel on Linux, > > to a local devpi server? Or do I need to get to a setup.py and do an > > upload from there? It seems a shame to build the wheel without need of > > a setup.py (I believe setup.py is only used behind the scenes), only > > to need a setup.py to upload the result. > > > > This makes me wonder about devpi and binary wheels on Linux: > > http://pythonwheels.com > > C extensions > > PyPI currently only allows uploading platform-specific wheels for > > Windows and Mac OS X. It is still useful to create wheels for these > > platforms, as it avoids the need for your users to compile the package > > when installing. > > > > I'm doing "pip -v -v -v wheel numpy" (for example), and I have a > > pip.conf and .pypirc (both pointing at our local devpi). > > > > Thanks! > > ___ > > 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 ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
