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 ubernost...@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 -- '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 rich...@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? Richard On Mon, 30 Mar 2015 at 15:50 James Bennett ubernost...@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 ___ 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 ubernost...@gmail.com wrote: On Mon, Mar 30, 2015 at 12:04 AM, Richard Jones rich...@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. -- '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] PyPI Rendering Switched
Thank you Donald! This is wonderful! On Sat, Jan 24, 2015 at 12:43 PM, Donald Stufft don...@stufft.io wrote: I've switched the rendering on PyPI away from using a big blog of code that was embedded into PyPI to the readme library (https://pypi.python.org/pypi/readme). Currently this only has a single API (``import readme.rst; readme.rst.render(...)``) however in the near future I want to provide a CLI for this so people can more easily test their READMEs against how PyPI renders them. The only real change should be some slight themeing differences. Some things might be valid that didn't used to be valid, and certain error conditions will now render escaped HTML instead of just failing to render. Note, for the next 24 hours you may need to force refresh your browser. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ 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] Requesting PyPI classifiers for Sphinx
+1 --Danny On Nov 24, 2014 5:07 PM, Takayuki Shimizukawa shimizuk...@gmail.com wrote: Bump. I'd like to request trove classifiers for the Sphinx like: Topic :: Documentation :: Sphinx Topic :: Documentation :: Sphinx :: Extension And additionally: Topic :: Documentation :: Sphinx :: Theme Thanks. On Thu Nov 20 2014 at 0:16:21 Takayuki Shimizukawa shimizuk...@gmail.com wrote: Hi, I'd like to request classifiers for the Sphinx like: Topic :: Documentation :: Sphinx Topic :: Documentation :: Sphinx :: Extension It would help us to search sphinx extensions and sphinx related tools. .. ex. sphinx-intl, sphinx-testing, Tinkerer, and sphinx extensions. .. refs: [sphinx-users]: Survey of Sphinx extensions [1]_ [2]_ Thanks. .. [1] https://groups.google.com/d/msg/sphinx-users/p82dKvqCUck/ BBoavGgXRcwJ .. [2] http://sphinxext-survey.readthedocs.org/en/latest/ -- Takayuki SHIMIZUKAWA http://about.me/shimizukawa ___ 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] Immutable Files on PyPI
+1 On Sep 29, 2014 7:29 AM, Jim Fulton j...@zope.com wrote: On Sun, Sep 28, 2014 at 3:31 PM, Donald Stufft donald.stu...@rackspace.com wrote: Hello All! I'd like to discuss the idea of moving PyPI to having immutable files. ... +1 Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ 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] Create formal process for claiming 'abandoned' packages
In order to claim a package as being abandoned it should undergo a formal process that includes: * Placement on a PUBLIC list of packages under review for a grace period to be determined by this discussion * Formal attempts via email and social media (twitter, github, et al) to contact the maintainer. * Investigation of the claimant for the rights to the package. The parties attempting to claim a package may not be the best representatives of the community behind that package, or the Python community in general. Why? * Non-reply does not equal consent. * Access to a commonly (or uncommonly) used package poses security and reliability issues. Why: Scenario 1: I could claim ownership of the redis package, providing a certain-to-fail email for the maintainers of PyPI to investigate? Right now the process leads me to think I would succeed in gaining access. If successful, I would gain complete access to a package used by hundreds of projects for persistence storage. Scenario 2: I could claim ownership of the redis package, while Andy McCurdy (maintainer) was on vacation for two weeks, or sabbatical for six weeks. Again, I would gain access because under the current system non-reply equals consent. Reference: In ticket #407 (https://sourceforge.net/p/pypi/support-requests/407/) someone who does not appear to be vetted managed to gain control of the (arguably) abandoned but still extremely popular django-registration on PyPI. They run one of several HUNDRED forks of django-registration, one that is arguably not the most commonly used. My concern is that as django-registration is the leading package for handling system registration for Python's most popular web framework, handing it over without a full investigation of not just the current maintainer but also the candidate maintainer is risky. Regards, Daniel Greenfeld pyda...@gmail.com ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Create formal process for claiming 'abandoned' packages
Hi Richard, On Fri, Sep 19, 2014 at 2:55 PM, Richard Jones rich...@python.org wrote: On 20 September 2014 04:47, Daniel Greenfeld pyda...@gmail.com wrote: In order to claim a package as being abandoned it should undergo a formal process that includes: * Placement on a PUBLIC list of packages under review for a grace period to be determined by this discussion This is not done at present. Can you suggest a public forum that would reach a useful audience? What about a page on PyPI that tracks packages undergoing this review? PyPI has a huge audience. In theory all this requires is just a few additional fields added. * Formal attempts via email and social media (twitter, github, et al) to contact the maintainer. This is done at present, using the contact details registered with pypi. Or other contact methods if that fails. I always default to asking the current maintainer of a package to transfer it to a new maintainer. It would be nice to have this documented on PyPI. I would be more than willing to write this down for you. * Investigation of the claimant for the rights to the package. The parties attempting to claim a package may not be the best representatives of the community behind that package, or the Python community in general. I'm not sure how I could do this reasonably given the breadth of packages in the index, and the size and number of Python communities. How could I possibly determine this? In the open source world, how do you vet someone, especially when the original maintainer is unresponsive? Honestly? I'm not sure either. I know the people that I know, and can research a segment of the community. However, I'm well aware that this is a tiny portion of who is actually using python. Why? * Non-reply does not equal consent. That's a reasonable statement, but if this were to be held then a large number of stagnating package listings would have remained in that state I concur. Which is why I suggested creating a page that tracks packages undergoing the transfer-of-ownership grace period. That would mean more eyes on the issue, as well as provide a means for eventually automating things in order to relieve you of the workload of maintenance. * Access to a commonly (or uncommonly) used package poses security and reliability issues. Why: Scenario 1: I could claim ownership of the redis package, providing a certain-to-fail email for the maintainers of PyPI to investigate? I attempt contact through other channels. I don't rely just on information provided by the requestor. Knowing you, I would be surprised if it were any other way. ;) I believe documenting this process of communication would cast light on the process. And would mean that you could more easily enlist others to help you. I would be honored to document this or any other part of this system. Reference: In ticket #407 (https://sourceforge.net/p/pypi/support-requests/407/) someone who does not appear to be vetted managed to gain control of the (arguably) abandoned but still extremely popular django-registration on PyPI. They run one of several HUNDRED forks of django-registration, one that is arguably not the most commonly used. My concern is that as django-registration is the leading package for handling system registration for Python's most popular web framework, handing it over without a full investigation of not just the current maintainer but also the candidate maintainer is risky. And my counter is that I get a lot of these requests, I do my best to try to contact the original maintainer, and in the absence of any other information I need to take the requestor at their word. In the case of the request above, I contacted the original maintainer directly, using an address I knew to work, and received no response. To me that correlated well with the indication that he wanted nothing to do with the package any longer. Someone keen enough had come forward to provide updated versions of the package, amongst what you claim are hundreds of such forks (recognising that github forks are a very poor method to judge how engaged someone is with a project). In light of that, I granted that person permission to provided updates for that project. Thanks for your thoughts. The procedure I use should be written down, I guess, but I'm the only person who follows it, so the motivation to do so is very low. Having maintained enough projects of my own, I really do understand your point of view. People ask for things, but it's rare that they will actually provide assistance. It's tiring and frustrating, since they always want you to put in more time, usually without offering to help in any way. So let me say right now that I want to help: * I will help with documenting the process. You can tell it to me in any format you want, written or verbal, and then I'll write it up. * I would like to help with modifying PyPI to create a tracking process for transfer
