Re: [Distutils] ANNOUNCE: Sunsetting of uploading to the legacy PyPI/TestPyPI

On 25 June 2017 at 01:18, Randy Syring wrote: > For what it's worth, for the projects that are almost ready to recommend, > but not quite there (like Flit per the discussion on issue 336), would it > hurt to have an "provisional" area to the key projects list that makes >

Re: [Distutils] Provide separate development and documentation URLs in PyPI metadata?

On 25 June 2017 at 03:51, Donald Stufft wrote: > It's only kind of mandatory. The spec says it is but nothing fails IIRC if > you omit it. Perhaps we should just deprecate it and move everything to > project urls. That's the direction I was going in PEP 426/459:

Re: [Distutils] ANNOUNCE: Sunsetting of uploading to the legacy PyPI/TestPyPI

Randy Syring writes: > […] would it hurt to have an "provisional" area to the key projects > list that makes people aware of the projects without "blessing" them > as Key Projects. It might hurt, yes. I am already quite confused by what is meant to be done in the Brave New

Re: [Distutils] ANNOUNCE: Sunsetting of uploading to the legacy PyPI/TestPyPI

* Donald Stufft , 2017-06-23, 10:21: Where can we find the exact versions of each that default to ‘pypi.org’ for uploads? Umm. Twine 1.8.0, Python 3.4.6, 3.5.3, 3.6.0, Not sure on 2.7, $ git tag --contains=7127b62702bd50bf44138e6f57334887cbcb5ca8 v2.7.13rc1 v2.7.13 --

Re: [Distutils] Provide separate development and documentation URLs in PyPI metadata?

On Sat, Jun 24, 2017, 10:51 Donald Stufft, wrote: > It's only kind of mandatory. The spec says it is but nothing fails IIRC if > you omit it. Perhaps we should just deprecate it and move everything to > project urls. > That sounds reasonable toe if the flexible, general case

Re: [Distutils] Provide separate development and documentation URLs in PyPI metadata?

On Sat, Jun 24, 2017, 10:49 Thomas Kluyver, wrote: > On Sat, Jun 24, 2017, at 06:34 PM, Brett Cannon wrote: > > Anyway, just an idea I had based on my flit experience yesterday plus a > tweet sent to me. (And if PyPI already supports this somehow then Thomas > should brace

Re: [Distutils] Provide separate development and documentation URLs in PyPI metadata?

It's only kind of mandatory. The spec says it is but nothing fails IIRC if you omit it. Perhaps we should just deprecate it and move everything to project urls. Sent from my iPhone > On Jun 24, 2017, at 1:48 PM, Thomas Kluyver wrote: > > This does leave open the

Re: [Distutils] Provide separate development and documentation URLs in PyPI metadata?

PyPI supports arbitrary key => URL mappings called project urls. The best way to implement this is probably to expose that feature with maybe some recommended keys to use (to avoid docs vs documentation fracture etc). As far as I know disutils2 was the only thing to ever support them. Sent

Re: [Distutils] Provide separate development and documentation URLs in PyPI metadata?

On Sat, Jun 24, 2017, at 06:34 PM, Brett Cannon wrote: > Anyway, just an idea I had based on my flit experience yesterday plus > a tweet sent to me. (And if PyPI already supports this somehow then > Thomas should brace for the feature request from me .) This prompted me to go and look at the

[Distutils] Provide separate development and documentation URLs in PyPI metadata?

When you go to PyPI.org for a project you will find a link to the "homepage". Now for some projects that's their development site, e.g. GitHub URL. For others it's their documentation site, e.g. Read the Docs. And not all projects link to both from their PyPI page (e.g. yesterday I noticed flit

Re: [Distutils] Can u provide metadata about the PyPI

https://kirankoduru.github.io/python/pypi-stats.html this may be relevant to your interests. some of the pypi info is available on google big table. On Sat, Jun 24, 2017 at 5:02 AM, Priya Lakshmi wrote: > Respected Python expert > > I just want a help. Can u provide

Re: [Distutils] ANNOUNCE: Sunsetting of uploading to the legacy PyPI/TestPyPI

For what it's worth, for the projects that are almost ready to recommend, but not quite there (like Flit per the discussion on issue 336), would it hurt to have an "provisional" area to the key projects list that makes people aware of the projects without "blessing" them as Key Projects. The

Re: [Distutils] Finishing up PEP 517

Nick has merged that PR, and the updated PEP is visible here: https://www.python.org/dev/peps/pep-0517/ Hopefully we're nearing a consensus on this now. If you're interested, please do have a read through the latest version. Thomas On Sat, Jun 24, 2017, at 02:44 PM, Thomas Kluyver wrote: > I

[Distutils] Can u provide metadata about the PyPI

Respected Python expert I just want a help. Can u provide us the metadata available about the modules in PyPI giant database. For example, we want the number of packages available, the number of downloads for each package, etc So we can think of doing some good maintenance work. thank you. G

Re: [Distutils] Finishing up PEP 517

I have prepared a PR against the PEP adding get_build_sdist_requires , and renaming a couple of the other hooks for clarity (get_build_wheel_requires, prepare_build_wheel_files): https://github.com/python/peps/pull/297 ___ Distutils-SIG maillist -

Re: [Distutils] ANNOUNCE: Sunsetting of uploading to the legacy PyPI/TestPyPI

On 24 June 2017 at 18:56, Thomas Kluyver wrote: > For reference, I switched the default upload server for flit in version > 0.11. Oh, I'd also missed that 0.11 published sdists now. Given that, I think we should start recommending flit for new pure Python projects (the

Re: [Distutils] ANNOUNCE: Sunsetting of uploading to the legacy PyPI/TestPyPI

For reference, I switched the default upload server for flit in version 0.11. On Sat, Jun 24, 2017, at 08:45 AM, Nick Coghlan wrote: > On 24 June 2017 at 15:24, Nick Coghlan wrote: > > https://packaging.python.org/guides/tool-recommendations/ is missing a > > section on

Re: [Distutils] ANNOUNCE: Sunsetting of uploading to the legacy PyPI/TestPyPI

On 24 June 2017 at 15:24, Nick Coghlan wrote: > https://packaging.python.org/guides/tool-recommendations/ is missing a > section on "Publishing platform" that explains the migration that is > currently in progress and covers what pypi.org currently handles > better than