Re: [Distutils] PEP 566 - metadata 1.3 changes

On Thu, Jan 18, 2018 at 5:58 AM, Nick Coghlan wrote: > On 18 January 2018 at 10:22, Dustin Ingram wrote: > >> Metadata 1.3 vs Metadata 2.0 > > > > I agree with Nick here that since this version is backwards-compatible, > that it > > should remain Metadata 1.3. >

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

>1.2 and not 2.0 is correct. I took a look at pkg_resources. It doesn't read Metadata-Version at all. It only cares about Version, and in wheels Requires-Dist and Provides-Extra. Everything else is ignored. So PEP 566 won't break anything there as long as someone checks that pkg_resources can

Re: [Distutils] PEP 566 - metadata 1.3 changes

It does, it's using the `packaging` module under the hood: >>> from pkg_resources import Requirement >>> Requirement.parse("requests >= 2.8.1") == Requirement.parse("requests (>= >>> 2.8.1)") True D. On Thu, Jan 18, 2018 at 10:56 AM, Daniel Holth wrote: >>1.2 and not 2.0 is

Re: [Distutils] Deprecating/Removing OpenID/Google login support for PyPI

Donald Stufft wrote: > > * Very few people actually are using OpenID or Google logins as it is. In one > month we had ~15k logins using the web form, ~5k using basic auth, and 62 > using Google and 7 using OpenID. This is a several orders of magnitude > difference. > * Regardless of how you

Re: [Distutils] library development patterns

Chris Withers wrote: > For me, I use travis-ci coupled with a few local virtualenvs for canary > versions. Some people like tox here, I never got on with it. For me, tox is transformative. While there are a couple of usability issues that my clone army seems to be remiss in fixing, for the most

Re: [Distutils] library development patterns

Nick Coghlan wrote: > The tox model is the one we decided to natively support in Fedora as > well - while there's only ever one "full" Python 3 stack in the main > repos (with all the distro API bindings, etc), there are also > interpreter-only packages for other still supported and/or still >

Re: [Distutils] library development patterns

I haven’t yet seen pyenv mentioned in this discussion. Having the ability to switch between Python versions for interactive exploration seems like an important piece for On Thu, Jan 18, 2018 at 11:18 AM Barry Warsaw wrote: > Nick Coghlan wrote: > > The tox model is the one we

Re: [Distutils] library development patterns

[Oops, my phone weirdly sent that email prematurely.] I haven’t yet seen pyenv mentioned in this discussion. Having the ability to switch between Python versions for interactive exploration seems like an important piece for library development, and pyenv makes this really easy. My only complaint

Re: [Distutils] library development patterns

PS - this is the pyenv / tox compatibility issue I had in mind: https://github.com/pyenv/pyenv-virtualenv/issues/202 And this I have found is the simplest workaround: https://github.com/pyenv/pyenv-virtualenv/issues/202#issuecomment-284728205 On Thu, Jan 18, 2018 at 1:04 PM, Chris Jerdonek

Re: [Distutils] library development patterns

On Thu, Jan 18, 2018 at 10:13 PM, Chris Jerdonek wrote: > PS - this is the pyenv / tox compatibility issue I had in mind: > https://github.com/pyenv/pyenv-virtualenv/issues/202 > > And this I have found is the simplest workaround: >