Re: [Distutils] latest setuptools appears to require six in a breaking way

AFAICT this is not really an issue as this is on the release notes: https://setuptools.readthedocs.io/en/latest/history.html#v34-0-0 You need to upgrade pip (cf 3rd paragraph): > #581: Instead of vendoring the growing list of dependencies that Setuptools > requires to function, Setuptools now

Re: [Distutils] latest setuptools appears to require six in a breaking way

be anyway necessary. Hope this problem will be either accepted or solved soon. Thanks -- M On Wed, Jan 25, 2017 at 9:20 AM, Chris Withers <ch...@simplistix.co.uk> wrote: > On 25/01/2017 16:44, Matthias Bussonnier wrote: >> >> AFAICT this is not really an issue as this is on

Re: [Distutils] Limit package installation to a specific Python version

Hi all, On Fri, Jan 20, 2017 at 2:56 PM, Nathaniel Smith wrote: > On Fri, Jan 20, 2017 at 1:56 PM, Lele Gaifax wrote: >> Hi all, >> >> do installers like pip and conda consult trove classifiers, or more generally >> is there a way to "mark" a package

Re: [Distutils] GSoC 2017 - Working on pip

Hi all, Assuming that all the requirements are wheels and coming from PyPI. Installed using a recent pip. How often do you think the resolution will be the same for all clients, and mostly be "pull everything from latest" ? If so, would it make sense to pre-compute thing on PyPI/warehouse at

Re: [Distutils] RFC 2: PEP 541 - Package Index Name Retention

> One thing we could possibly do is provide the ability for, as part of the > relqunishing process, “lock” the old versions that were uploaded so that the > new owner can neither delete them or upload new files for them AND set a > “minimum version” for new uploads for that project. This could

Re: [Distutils] RFC 2: PEP 541 - Package Index Name Retention

On Mon, Jan 16, 2017 at 1:18 PM, Chris Rose wrote: > The tricky part there is that "being used" is a tough concept to define. > Over what time period? What amount of downloading counts as "used"? > > I believe these concepts need to be made very clear, because the impact of >

[Distutils] Pep 440 question/clarification Version specifiers no "Or" available

Hi all, In the line of recent discussions[1] about releasing some packages only for some versions of Python. I was reading pep 440 and in particular the "Version specifier section". The following sentence caught my eye: > The comma (",") is equivalent to a logical and operator: a candidate

Re: [Distutils] Module Installation Issues

On Tue, Sep 13, 2016 at 3:55 PM, Donald Stufft wrote: > Perhaps a better idea would be to add some smarts to the REPL (but not to > Python itself) that would detect something like: > pip install > > And print a better error message that gives a better indication about

Re: [Distutils] reproducible builds

On Fri, Mar 17, 2017 at 10:19 AM, Robin Becker wrote: > An issue has been raised for reportlab to support a specific environment > variable namely SOURCE_DATE_EPOCH. The intent is that we should get our time > from this variable rather than time.localtime(time.time()) so that

Re: [Distutils] A possible refactor/streamlining of PEP 517

On Thu, Jul 6, 2017 at 10:57 AM, Thomas Kluyver wrote: > Thank-you all for the discussion and the attempts to accommodate flit, > but I'll bow out now. It's become clear that the way flit approaches > packaging is fundamentally incompatible with the priorities other people >

Re: [Distutils] Malicious packages on PyPI

On Thu, Jun 1, 2017 at 3:20 PM, Jannis Gebauer wrote: > This makes me remember > https://hackernoon.com/building-a-botnet-on-pypi-be1ad280b8d6 on a related > note. > > > Yep, that’s basically the same thing. Instead of using package names of > builtins, the attacker is using a

Re: [Distutils] Reproducible builds (Sdist)

M, Nick Coghlan <ncogh...@gmail.com> wrote: > On 30 September 2017 at 06:02, Thomas Kluyver <tho...@kluyver.me.uk> wrote: >> On Fri, Sep 29, 2017, at 07:16 PM, Matthias Bussonnier wrote: > > For distro level reproducible build purposes, we typically treat the > pub

[Distutils] Reproducible builds (Sdist)

Hello there, I'm going to ask questions about Reproducible Builds, a previous thread have been started in March[1], but does not cover some of the questions I have. In particular I'm interested in the reproducible build of an _sdist_. That is to say the process of going from a given commit to

Re: [Distutils] Reproducible builds (Sdist)

sha256", and I can do the same independently. -- M On Fri, Sep 29, 2017 at 1:02 PM, Thomas Kluyver <tho...@kluyver.me.uk> wrote: > On Fri, Sep 29, 2017, at 07:16 PM, Matthias Bussonnier wrote: >> Second; is there a convention to store the SDE value ? I don't seem to >> be ab

Re: [Distutils] Immutability of Release Metadata in Warehouse

One case I could see is the use of the requires_python metadata. It was not included in the recent release of Django 2.0 (which is py 3 only) and making a new release will be useless as pip on py2 will still see Django 2.0.0 as Py 2 compatible download it and crash. I'm going to assume with time

Re: [Distutils] Immutability of Release Metadata in Warehouse

..@kluyver.me.uk> wrote: On Tue, Dec 19, 2017, at 9:10 PM, Matthias Bussonnier wrote: One case I could see is the use of the requires_python metadata. It was not included in the recent release of Django 2.0 (which is py 3 only) and making a new release will be useless as pip on py2 will stil

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

> * 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. Not opposing to open-id/Google-ID removal, but I would love