Re: [Distutils] PEP 345, 566, 508 version specifiers and OR clauses

It seems like a small amount of convenience in exchange for a significant increase in complexity to me. FYI, some previous discussion on the topic can be found here: https://mail.python.org/pipermail/distutils-sig/2016-September/029651.html And also here:

Re: [Distutils] RFC: PEP 566 - Metadata for Python Software Packages 1.3

Ah, I see, by "other two" I thought you meant the other two new fields. Looking at https://www.python.org/dev/peps/pep-0566/ might make it more clear that I originally intended the "New in Version 1.3" and "Changed in Version 1.3" headings to only be under the "Fields" heading, so the outline

Re: [Distutils] RFC: PEP 566 - Metadata for Python Software Packages 1.3

> I was a bit confused at first by the fact that you describe > environment markers but not where they are allowed. On checking, I > find that this is defined in version 1.2 (PEP 345). It might be worth > a small clarification that this (and name and version specifiers) are > still used in the

[Distutils] RFC: PEP 566 - Metadata for Python Software Packages 1.3

: $Revision$ Last-Modified: $Date$ Author: Dustin Ingram <di@di.codes> Discussions-To: distutils-sig Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 1-Dec-2017 Python-Version: 3.x Post-History: Replaces: 345 Abstract This PEP describes the changes between versio

Re: [Distutils] RFC: PEP 566 - Metadata for Python Software Packages 1.3

After working a bit on an implementation of the "JSON-compatible Metadata" section in this PEP, I'm noticing that it might be more useful if it had the following step instead for canonicalizing the field names: > #. All transformed keys should be reduced to lower case. Hyphens should be >

Re: [Distutils] PEP 566 - metadata 1.3 changes

> Given that, I think it would be reasonable to finally Withdraw PEP 426 > (rather than continuing to defer it), and have PEP 566 define metadata > version 2.1, so that it's unambiguously the latest metadata version. I'm amenable to any version number that is > 1.2 and not 2.0. D.

Re: [Distutils] PEP 566 - metadata 1.3 changes

reak anything there as long as > someone checks that pkg_resources can handle the optional parenthesis which > seems likely. > > On Thu, Jan 18, 2018 at 11:37 AM Dustin Ingram <di@di.codes> wrote: >> >> > Given that, I think it would be reasonable to finally Withdraw PEP

Re: [Distutils] PEP 566 - metadata 1.3 changes

Hi all, Thanks very much for all your suggestions and feedback. I want to take a moment to summarize & respond to some outstanding issues from this thread & previous threads. [0][1][2] First, I'd like to reiterate that the goal of this PEP is to: 1. Define the Core Metadata document as the

Re: [Distutils] Current status of ``setup.py register --list-classifiers``

Yes, it seems broken. With the default repository of: https://upload.pypi.org/legacy/ this would look at: https://upload.pypi.org/legacy/?:action=list_classifiers but the correct location would be: https://pypi.org/pypi?:action=list_classifiers Given that the `register` command is

Re: [Distutils] PEP 566 - Package metadata version 2.1

I've updated the PEP to include the message body as Description. https://www.python.org/dev/peps/pep-0566/ I don't think there are any other outstanding issues, so this should be ready for Daniel's review. Thanks, D. On Thu, Feb 15, 2018 at 2:09 PM, Trishank Kuppusamy

Re: [Distutils] PEP 566 - Package metadata version 2.1

Sounds good. I've made the following edits, does this suffice? @ pep-0566.rst:84 @ Name The specification for the format of this field is now identical to the distribution name specification defined in PEP 508. +Description +::: +In addition to the

[Distutils] Re: Oct 27-28: Bloomberg sponsoring packaging sprint

Hi folks! This event is happening in about two months. You can find more details and RSVP at the following links: NYC: 10/27: https://generalassemb.ly/education/bloomberg-open-source-weekend-pypa/new-york-city/58377 10/28:

[Distutils] Environment markers for GPU/CUDA availibility

Hi all, trying to pull together a few separate discussions into a single thread here. The main issue is that currently PEP 508 does not provide environment markers for GPU/CUDA availability, which leads to problems for projects that want to provide distributions for environments with and without

[Distutils] Re: Environment markers for GPU/CUDA availibility

On Tue, Sep 4, 2018 at 11:33 AM Jeremy Stanley wrote: > > Yes. If you haven't tried running a mirror of PyPI lately you're > likely not to have noticed, but the various nightly builds for > tensorflow seem to be the majority of the data on PyPI now. I'm sure > it's a very neat and useful tool,

[Distutils] Re: Oct 27-28: Bloomberg sponsoring packaging sprint

Hi everyone! Bloomberg is hoping to sponsor one more mentor to attend in both NYC and London, please reach out to me directly if you are interested! D. On Mon, Aug 27, 2018 at 11:16 AM Dustin Ingram wrote: > > Hi folks! This event is happening in about two months. > > You can find

Re: [Distutils] PEP 566 - metadata 1.3 changes

I've updated the PEP to use "2.1" as the version: https://www.python.org/dev/peps/pep-0566/ D. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Facing a strange issue while uploading my package using devpi

This is likely the reason why: https://github.com/devpi/devpi/issues/524#comment-379020251 On Sat, Apr 7, 2018, 10:45 PM Vinay Sharma wrote: > Thanks to all who provided their valuable comments for this Issue. > > Based upon the pointer provided by Dan, figured out there was

Re: [Distutils] [Python-ideas] Pypi private repo's

This was recently discussed on the Packaging-WG mailing list. To summarize, there are a few key reasons why this would be challenging: 1) The PSF is a non-profit. Taking on work generally in the domain of for-profit enterprises might jeopardize our tax-exempt status. 2) PyPI relies heavily

Re: [Distutils] Facing a strange issue while uploading my package using devpi

Some more information about the environment you built your distribution in would be helpful. The `PKG-INFO` file is not derived from your README, if you un-tar the source distribution, is there a file named `PKG-INFO` in the top-level directory? What's the result of running using the `pkginfo`

[Distutils] Re: setuptools API compatibility

Hi Brian, I work on the team that develops the App Engine Python 3.7 runtime. You're correct, by default we use the latest versions of setuptools, pip and wheel for the runtime. We do this to ensure that the runtime is always compatible with the latest features that newly created packages may be

[Distutils] Re: History of python packaging

Hi Konstantin, You might find my PyCon talk "How Python Packaging Works" useful for a general timeline: https://www.youtube.com/watch?v=AQsZsgJ30AE The section "How did we get here" from Nick Coghlan's essay on a core packaging API is quite a bit more detailed:

[Distutils] Re: Announcing Wheelodex

What a great tool! I can see myself using this to explain to folks why the metadata for a given release is broken or incorrect. It would be really nice (for me) to be able to link to specific lines in the metadata file, but I figure most people don't need that feature. Very interesting to see the

[Distutils] Re: Idea: perennial manylinux tag

FYI, I've started a discussion on the next manylinux spec here: https://discuss.python.org/t/the-next-manylinux-specification/ On Thu, Dec 6, 2018 at 4:21 AM Nick Coghlan wrote: > On Tue, 4 Dec 2018 at 23:51, Matthias Klose wrote: > > On 30.11.18 19:10, Brett Cannon wrote: > > > And just to

[Distutils] Re: wrong SHA256 on setuptools

)= 6e4eec90337e849ade7103723b9a99631c1f0d19990d6e8412dc42f5ae8b304d On Thu, Mar 21, 2019 at 12:37 PM Dustin Ingram wrote: > How are you generating your sum? Looks right to me: > > $ wget -q > https://files.pythonhosted.org/packages/c2/f7/c7b501b783e5a74cf1768bc174ee4fb0a8a6ee5af6afa92274ff964703e0/setuptools-40.8.0.zip > $ SH

[Distutils] Re: wrong SHA256 on setuptools

How are you generating your sum? Looks right to me: $ wget -q https://files.pythonhosted.org/packages/c2/f7/c7b501b783e5a74cf1768bc174ee4fb0a8a6ee5af6afa92274ff964703e0/setuptools-40.8.0.zip $ SHA256(setuptools-40.8.0.zip)= 6e4eec90337e849ade7103723b9a99631c1f0d19990d6e8412dc42f5ae8b304d On Thu,

[Distutils] Re: API for SHA-256 fingerprints

Hashes are also available via PyPI's JSON API . On Tue, Feb 12, 2019 at 7:15 AM Tzu-ping Chung wrote: > I believe you’re looking for the PEP 503 simple API > . This is what pip uses to > find the

[Distutils] Re: API for SHA-256 fingerprints

> > Most likely (someone more familiar with Warehouse could answer this) > Warehouse will select sha256 whenever it is available, so the simple API > may be just as good for you. But it's something to consider. > The simple API will always have the sha256 digest, for every file.

[Distutils] Re: Seeking a new maintainer for packaging.python.org and Twine.

Sorry to see you go, Thea! You've done a great job. I'd be happy to help maintain both these projects. On Fri, Jul 19, 2019 at 5:33 PM Thea Flowers via Distutils-SIG < distutils-sig@python.org> wrote: > Hi friends! > I'm stepping away from several things in the Python community. I've served >

[Distutils] Re: Problem with the packaging exercise

Hi Douglas, can you add this as a new issue on https://github.com/pypa/packaging.python.org/issues? On Fri, Oct 11, 2019 at 5:13 PM Douglas Coup wrote: > Hello all. > > I recently went through the packaging exercise that's documented here: >

[Distutils] Re: Deleted PyPI project

to see response content. > HTTPError: 400 Client Error: This filename has already been used, use a > different version. See https://pypi.org/help/#file-name-reuse for url: > https://upload.pypi.org/legacy/ > > Thanks a lot in advance. > > Best; > Sabry > > > >

[Distutils] Re: Deleted PyPI project

Hi Sabry, you should be able to republish the package, but you'll need to change the version number to make a new release. Like Chris said, please file an issue at https://github.com/pypa/pypi-support/issues/new/choose if you have any issues. On Wed, Feb 12, 2020 at 11:52 AM Chris Wilcox wrote:

[Distutils] Re: Packaging Summit 2020: Save the Date!

Thank you Paul for organizing! On Tue, Jan 14, 2020 at 7:37 PM Paul Ganssle wrote: > > Greetings one and all! > > Each year millions of eyes around the world eagerly wait at their computer > with baited breath to learn the timing of the most fabulous, extravagant, > decadent and

[Distutils] Re: twine upload & network robustness

The latter. On Fri, Aug 7, 2020 at 4:37 AM Robin Becker wrote: > Because of covid-19 I am working a lot from home so my network is likely > less robust. > > I was wondering about what happens if I upload with twine to pypi and > halfway through my network fails. > > Is the uploaded filename

[Distutils] Re: PEP 541 / Transfer of https://pypi.org/project/Augur/ to my project https://github.com/chaoss/augur

Hi, please open an issue at https://github.com/pypa/pypi-support/ On Wed, Jul 8, 2020 at 12:59 PM Sean Goggins wrote: > > Hi, > > I am the code owner for the Augur Open Source Software project, which is part > of the Linux Foundation’s CHAOSS Project. One of my developers secured our > PiPy