[Distutils] PEP 592 Title: Adding "Yank" Support to the Simple API

Just mentioning this here incase anyone is not following along on discuss.python.org : I’ve written a PEP that is going to add support for “yanking” files in the simple api. This will act as a softer form of file deletion that solves a lot of the breakages that

[Distutils] Re: API for SHA-256 fingerprints

> On Feb 12, 2019, at 1:27 PM, Dustin Ingram wrote: > > 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

[Distutils] Re: Update PEP 508 to allow version specifiers

> On Jan 29, 2019, at 10:15 AM, Xavier Fernandez > wrote: > > I agree that such specifier would make little sense but why add a new syntax > "foo-1 @ url" when "foo==1 @ url" (where ==1 is a version specifier as > defined in PEP 508) would perfectly fit the bill ? Well foo-1 wouldn’t work

[Distutils] Re: Update PEP 508 to allow version specifiers

> On Jan 29, 2019, at 9:48 AM, Xavier Fernandez wrote: > > I disagree that it *needs* the name: since the link is declared as a > dependency, the installer will necessarily need to check/download it at some > point to install it and could discover the package name at that point, just > like

[Distutils] Re: Update PEP 508 to allow version specifiers

> On Jan 29, 2019, at 9:43 AM, Paul Moore wrote: > > But direct URLs to github repos are a different matter, and are > frankly just wrong - by their nature a github repo is a changing > object, and so will never map to a "specific artifact to install". FWIW, Paul’s statement is supported by

[Distutils] Re: Update PEP 508 to allow version specifiers

> On Jan 29, 2019, at 9:02 AM, Xavier Fernandez wrote: > > Thanks Jan for raising this issue. > > On Tue, Jan 29, 2019 at 10:21 AM Tzu-ping Chung > wrote: > I’m wondering, why is it needed to specify both a version and a link? I > assume the version specifier

[Distutils] Re: Update PEP 508 to allow version specifiers

You can also just stick files in a directory and use pretty much any web server that generates an automatic index from it. > On Jan 29, 2019, at 8:35 AM, Bernat Gabor wrote: > > I'm not sure I agree that setting up a private repository is that hard. Devpi > does an excellent job for open

[Distutils] Re: Intent to add a "Packaging" category to discuss.python.org

> On Nov 3, 2018, at 7:27 AM, Paul Moore wrote: > > On Sat, 3 Nov 2018 at 01:27, Donald Stufft wrote: >> >> Just an FYI, I’m going to ask the discuss.python.org admins to add a >> Packaging category to that discourse instance for the discussion of >&g

[Distutils] Intent to add a "Packaging" category to discuss.python.org

Just an FYI, I’m going to ask the discuss.python.org admins to add a Packaging category to that discourse instance for the discussion of packaging in Python, basically as a sister discussion location to distutils-sig. I plan to primarily participate and centralize

[Distutils] Re: setuptools configuration in pyproject.toml

> On Sep 26, 2018, at 10:23 AM, Paul Moore wrote: > > On Wed, 26 Sep 2018 at 15:11, Paul Ganssle > wrote: >> >> Sorry it's taken me a while to respond in this thread, but I think I'd >> like to slightly reframe the question away from `setuptools` >> specifically -

[Distutils] Re: Distlib vs Packaging (Was: disable building wheel for a package)

> On Sep 21, 2018, at 8:14 AM, Paul Moore wrote: > > On Fri, 21 Sep 2018 at 11:41, Nick Coghlan <mailto:ncogh...@gmail.com>> wrote: >> >> On Fri, 21 Sep 2018 at 05:47, Donald Stufft wrote: >>> On Sep 20, 2018, at 3:35 PM, Paul Moore wrote: >>&g

[Distutils] Re: Distlib vs Packaging (Was: disable building wheel for a package)

> On Sep 20, 2018, at 3:35 PM, Paul Moore wrote: > > I don't think anyone's even spoken to the pip maintainers (yet?) about > supporting the pipfile format That comes from me, I initially wrote the Pipfile as a proof of concept / sketch of an API for replacing the requirements.txt format,

[Distutils] Re: Distlib vs Packaging (Was: disable building wheel for a package)

> On Sep 20, 2018, at 2:29 PM, Bert JW Regeer wrote: > > pip not seeing any improvements is something I think will be sad. I don't use > pipenv, but use poetry which uses pip behind the scenes to do installation. I > also use flit. For either of those cases I would think it sad that pipenv

[Distutils] New virtualenv maintainer

We don’t typically bother to make big announcements on distutils-sig for maintainers of projects, however I’m making an exception in this case because of the recent threads on virtualenv maintenance. The current core team of virtualenv agrees that it is an important package, and deserves

[Distutils] Re: Distlib vs Packaging (Was: disable building wheel for a package)

> On Sep 20, 2018, at 8:12 AM, Donald Stufft wrote: > > Depending on how vital a particular bit of functionality is to pip, we’re > likely going to want most libraries that are pulling functionality out of pip > to live under the PyPA banner, and ideally should be

[Distutils] Re: Distlib vs Packaging (Was: disable building wheel for a package)

> On Sep 19, 2018, at 11:54 PM, Dan Ryan wrote: > > Since you mentioned following along, here's what we're working on right now: > > https://github.com/sarugaku/requirementslib > -- abstraction layer for parsing > and converting various

[Distutils] Re: Distlib vs Packaging (Was: disable building wheel for a package)

> On Sep 19, 2018, at 1:14 PM, Tzu-ping Chung wrote: > > I feel the plan is quite solid. This however leaves us (who want a Python > implementation and interface to do what pip does) in an interesting place. So > I can tell there are a couple of principles: > > 1. Do not use pip internals >

[Distutils] Re: Distlib vs Packaging (Was: disable building wheel for a package)

> On Sep 19, 2018, at 5:17 AM, Paul Moore wrote: > >> >> >> What is the current situation regarding distlib vs packaging and various >> pieces in pip? Many parts of distlib seems to have duplicates in either >> packaging or pip/setuptools internals. I understand this is a historical >>

[Distutils] Re: disable building wheel for a package

> On Sep 18, 2018, at 4:31 PM, Dan Ryan wrote: > > As a consequence even though there are other libraries that may provide some > of this functionality, pip has the reference implementation and that > contains some significant additional logic. I don't imagine that pip is > going to simply

[Distutils] Re: Opinions on requiring younger glibc in manylinux1 wheel?

> On Sep 18, 2018, at 8:44 AM, Olivier Grisel wrote: > > That's an interesting proposition. > > Would pip be able to automatically select the most recent compatible wheel > when two are available on PyPI? Yes. Well “recent” isn’t the right way to describe it. Basically when pip is looking

[Distutils] Re: manylinux1 guidelines for zlib?

> On Sep 5, 2018, at 9:30 AM, Tzu-ping Chung wrote: > > Isn’t zlib only required for compression? It is my impression that zipfile’s > decompressor is pure Python, > and only depends on zlib if the archive is encrypted (but wheels are never > encrypted). > > zlib also does not provide

[Distutils] Re: manylinux1 guidelines for zlib?

> On Sep 4, 2018, at 6:06 AM, Alex Walters wrote: > > Since zlib is a dependency of python, the assumption has to be that it is > already present. It is technically an optional dependency of Python, though I don’t think you can install wheels without zlib present since wheels are zip files

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

> On Sep 4, 2018, at 1:36 PM, Wes Turner wrote: > > What's Fastly's monthly/yearly cost? The PSF “Bill” for Fastly in August was $132,086.96 before the discount which brought it down to $0. I think that might be missing a thousand or two in extra features that were manually enabled for our

[Distutils] Re: Three clarification questions about PEP 425 and PyPy3

> On Aug 30, 2018, at 9:54 PM, Brett Cannon wrote: > > I initially thought 'packaging', but I also don't want to care about Python > 2. :) So I haven't decided yet. At worst this just leads to a clearer > understanding of how tools should do wheel compatibility matching. If you want to get

[Distutils] Re: Three clarification questions about PEP 425 and PyPy3

> On Aug 30, 2018, at 9:05 PM, Brett Cannon wrote: > > Basically I'm trying to figure out what tags pip and various tools should be > matching when determining what wheel to download from PyPI (so that diff is > what pip matches against now in two scenarios and how I think what is matched >

[Distutils] Re: Three clarification questions about PEP 425 and PyPy3

> On Aug 30, 2018, at 3:07 PM, Daniel Holth wrote: > > Package version resolution is a completely different and np-complete problem. > https://en.wikipedia.org/wiki/Boolean_satisfiability_problem > They are related in the sense

[Distutils] Re: Three clarification questions about PEP 425 and PyPy3

> On Aug 30, 2018, at 1:59 PM, Nathaniel Smith wrote: > > That's the theory, but I think these tags are useless in practice. > > If you're on py35 and pip sees a wheel with py36 as the tag, then it falls > back to building from the sdist. For ABI-related tags this makes sense, > because

[Distutils] PyPI will no longer accept compromised passwords!

I just wanted to give everyone a heads up that PyPI will no longer accept passwords that have been published in data breaches. For background you can take a look at https://github.com/pypa/warehouse/pull/4541 . For high level overview see

[Distutils] Re: Is ensurepip still a thing?

> On Aug 7, 2018, at 11:43 AM, Chris Barker - NOAA Federal via Distutils-SIG > wrote: > >> IIRC, ensurepip by design doesn't go to the internet , so it will only >> ever upgrade to the version bundled with Python > > Now I’m really confused — if pip is already bundled with Python, then > what

[Distutils] Re: Is ensurepip still a thing?

> On Aug 7, 2018, at 3:46 AM, Paul Moore wrote: > > IIRC, ensurepip by design doesn't go to the internet , so it will only > ever upgrade to the version bundled with Python (from the docs "To > ensure the installed version of pip is *at least as recent as the one > bundled with ensurepip*, pass

[Distutils] Discussion on handling various User Agents in Linehaul/BigQuery on PyPI

Hey there! I’m trying to sort out what people are expecting behavior wise from the BigQuery statistics for PyPI. I’ve opened up an issue on Linehaul (the daemon that handles processing those statistics) at https://github.com/pypa/linehaul/issues/44

[Distutils] Re: packaging guide and private packages index

> On Jul 31, 2018, at 12:38 PM, Alex Becker wrote: > > Packagecloud only supports the "simple" index API, which makes it slower for > tools to work with and presumably less future-proof. It's particularly > annoying to me, since I've been working on a dependency management system and > only

[Distutils] Re: Export status for setuptools (18.0.1)

I believe the answer is it is Not Controlled, however, I am not an authoritative source on that, and if you’re shipping a finished product that includes Python or Python libraries, you should probably get with whoever is responsible for compliance and have them do the compliance work here.

[Distutils] Re: Make an ordered list of sdists to be installed?

The things you get from pip download should be order independent. It won’t include build dependencies though. > On Jul 23, 2018, at 5:48 AM, Thomas Kluyver wrote: > > Hi all, > > Do we know of any tool that can, given the name of one or more packages, > follow dependency chains and produce a

[Distutils]Re: PEP 518 - pyproject.toml with no build-system.requires

> On Jul 16, 2018, at 5:22 AM, Paul Moore wrote: > > 1. If [build-system] is present but requires is missing, raise an error. > 2. If [build-system] is missing, they can take one of the following > two approaches: > a) Act as if pyproject.toml is missing altogether > b) Act as if

[Distutils]Re: pypi/twine complains about license

> On Jul 12, 2018, at 3:45 AM, Robin Becker wrote: > > Am I right in assuming that uploading a different file with the same name > will cause an error? Correct.-- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org

[Distutils]Re: pypi/twine complains about license

> On Jul 11, 2018, at 12:37 PM, Nathaniel Smith wrote: > > Possibly PyPI is noticing that the file you're trying to upload is identical > to the one that's already there and counting that as a "successful upload"? Yes, if you try to upload the same file twice (same as in, the hashes match

[Distutils] Re: sudo pip install: install pip files into /usr/local on Linux?

> On May 25, 2018, at 12:44 PM, Thomas Kluyver wrote: > > It's more annoying for scripts - on common Linux distributions, the user > scripts location ~/.local/bin is not on PATH by default. It’s on $PATH by default in Fedora I think.-- Distutils-SIG mailing list

[Distutils] Improving Communication

Currently in the packaging space, we have a number of avenues for communication, which are: - distutils-sig - pypa-dev - virtualenv-users - Other project specific mailing lists - IRC - gitter - Various issue trackers spread across multiple platforms. - Probably more places I’m not remembering.

Re: [Distutils] New PyPI launched, legacy PyPI shutting down April 30

> On Apr 16, 2018, at 2:14 PM, Joni Orponen wrote: > > On Mon, Apr 16, 2018 at 7:27 PM, Laura Hampton > wrote: > Monday April 30 (2018-04-30): We plan to shut down legacy PyPI > https://legacy.pypi.org

Re: [Distutils] Package metadata: which fields are optional

> On Apr 15, 2018, at 3:31 AM, Thomas Kluyver wrote: > > The core metadata specification > (https://packaging.python.org/specifications/core-metadata/ ) notes whether > each field is optional. However there are some discrepancies with my > understanding: > > -

Re: [Distutils] Announcement: Pip 10 is coming, and will move all internal APIs

> On Apr 14, 2018, at 4:57 PM, Matthew Brett wrote: > > Is the suggestion to use the `_internal` import, or carry a copy of > the pep425tags code myself, that I have to keep up to date with the > internal pip copy? That would also involve me copying the `glibc` > part

Re: [Distutils] Any thoughts on supporting e.g. Alpine Linux? (was: PEP 571: Any further manylinux2010 concerns or questions?

> On Mar 31, 2018, at 11:18 AM, Brett Cannon wrote: > > The discussion of distro-specific wheels has been brought up. I believe they > are technically supported if you have your own index server, but PyPI > doesn't, I believe, to keep an explosion of wheels people can't

Re: [Distutils] TLS support policy & PyPI communications

Just as an FYI, as of this morning we’ve started doing brownouts of the deprecated TLS versions. For the first 10 minutes of each hour anyone attempting to access PyPI with TLSv1.0 or TLSv1.1 will get a 403 response with an informative error. As we get closer to the deadline I will be ramping

Re: [Distutils] Renaming this list to python-packaging

I don’t think we can rename a mailing list easily, we can create a new one and archive the old one but that has a lot of churn and breaks people’s filters, etc. > On Mar 19, 2018, at 1:39 PM, Paul Moore wrote: > > On 19 March 2018 at 17:30, Pradyun Gedam

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

As folks are likely aware, legacy PyPI currently supports logging in using OpenID and Google Auth while Warehouse does not. After much deliberation, I’ve decided that Warehouse will not be implementing OpenID or Google logins, and once we shutdown legacy PyPI, OpenID/ and Google logins to PyPI

Re: [Distutils] Immutability of Release Metadata in Warehouse

> On Dec 19, 2017, at 4:30 PM, Matthias Bussonnier > wrote: > > One alternative is have the ability to "yank" a package. Make it still > available, but installable only when pinned explicitly. I believe that's what > Rust does. The ability to yank a package is

Re: [Distutils] Immutability of Release Metadata in Warehouse

> On Dec 19, 2017, at 2:51 PM, Alex Grönholm wrote: > > Couldn't Warehouse validate the description, and reject the upload (with an > appropriate message) if it doesn't pass? This at least would eliminate those > ugly project pages that failed to render...there are a

[Distutils] Immutability of Release Metadata in Warehouse

For those who are not aware, legacy PyPI would allow you to run ``twine register`` on a release that had already been created in order to modify the metadata that PyPI had recorded for that release (keyed by version number). This wasn’t a super widely used feature, but it’s primary use case was

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

> On Dec 13, 2017, at 7:17 PM, Barry Warsaw wrote: > > I understand that OR clauses aren't supported under any syntax > currently, but as PEPs 566 and 508 are still open/active, wouldn't it be > reasonable to support something like this explicitly? I personally think this is

Re: [Distutils] Outstanding questions for PEP 541: Package Index Name Retention

> On Nov 29, 2017, at 11:10 PM, Sumana Harihareswara wrote: > > While getting up to speed on Warehouse I saw how many package transfer > requests are waiting for PEP 541[0] to be accepted, so I thought it > might be helpful to round up what I see as the outstanding

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

> On Dec 5, 2017, at 4:02 PM, Nathaniel Smith wrote: > > I haven't followed this so sorry if this is an annoying comment, but having > read this description I still don't really understand what Provides-Extra is > doing. Don't packages already include extra information? What

[Distutils] Funding Warehouse Development/Deployment

As I’m sure most or everyone on this list is aware, the work to replace PyPI with Warehouse has been underway for quite awhile. I’m happy to say that we’ve now got funding from a MOSS grant that should finally help us get this across the finish line and deployed for “real”. You can read more

Re: [Distutils] What's the use case of testpypi?

> On Oct 30, 2017, at 1:41 PM, Toshio Kuratomi wrote: > > I figured that unless I > asked, I would never know the answer :-) > TestPyPI has a couple of use cases, and it’s not very good at any of them. One use case is to serve as a staging site for production PyPI to

[Distutils] Disabling non HTTPS access to APIs on PyPI

Historically PyPI was only available over either HTTP or unvalidated HTTPS, and over time we’ve been pushing more and more traffic onto HTTPS. In Warehouse the decision was made to *not* redirect “API” URLs from HTTP to HTTPS, but to rather return an error accessing them from HTTP. This is

Re: [Distutils] Announcement: Pip 10 is coming, and will move all internal APIs

> On Oct 21, 2017, at 10:30 PM, Nick Coghlan wrote: > > However, none of that impacts the question of whether `pip.main()` runs code > in the current process or implicitly runs it in a subprocess - `pip` doesn't > import the modules it installs either way, so it will all

Re: [Distutils] Announcement: Pip 10 is coming, and will move all internal APIs

> On Oct 21, 2017, at 2:15 PM, Brett Cannon wrote: > > as long as the module isn't already imported it's fine. Negative imports get cached too don’t they?___ Distutils-SIG maillist - Distutils-SIG@python.org

Re: [Distutils] Announcement: Pip 10 is coming, and will move all internal APIs

> On Oct 20, 2017, at 9:30 AM, Paul Moore wrote: > > On 20 October 2017 at 14:26, Matthew Brett wrote: >> Thanks for the heads-up. >> >> Will y'all be doing a PyPI pre-release so we can test with `pip >> install --pre -U pip`? > > We've not yet

Re: [Distutils] Entry points: specifying and caching

> On Oct 20, 2017, at 9:35 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > > On 20 October 2017 at 23:19, Donald Stufft <don...@stufft.io > <mailto:don...@stufft.io>> wrote: > One that I was helping someone debug just the other day is that they’re super >

Re: [Distutils] Entry points: specifying and caching

On Oct 20, 2017, at 8:41 AM, Thomas Kluyver <tho...@kluyver.me.uk> wrote: > > On Fri, Oct 20, 2017, at 01:36 PM, Donald Stufft wrote: >> Entry points have a lot of problems and I know of multiple systems that have >> either moved away from them, had to hack aroun

Re: [Distutils] Entry points: specifying and caching

> On Oct 20, 2017, at 8:34 AM, Nick Coghlan wrote: > > You're acting like you believe you have veto power over this topic. You don't > - it's not a PyPI related concern, and it doesn't require any changes to pip > or warehouse. > > I'd certainly be *happier* if you were

Re: [Distutils] Entry points: specifying and caching

> On Oct 20, 2017, at 8:23 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > > On 20 October 2017 at 22:10, Donald Stufft <don...@stufft.io > <mailto:don...@stufft.io>> wrote: > If I could guess, I’d say it hasn’t changed in years because setuptools

Re: [Distutils] Entry points: specifying and caching

> On Oct 20, 2017, at 8:06 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > > On 20 October 2017 at 21:15, Donald Stufft <don...@stufft.io > <mailto:don...@stufft.io>> wrote: > Tell you what, I’ll drop everything today and write up a PEP that adds > metadata

Re: [Distutils] Entry points: specifying and caching

> On Oct 20, 2017, at 7:57 AM, Thomas Kluyver <tho...@kluyver.me.uk> wrote: > > On Fri, Oct 20, 2017, at 12:50 PM, Donald Stufft wrote: >> * Since it is a packaging standard, then it is expected that all >> packaging tools will be updated to work with it. > > W

Re: [Distutils] Entry points: specifying and caching

> On Oct 20, 2017, at 7:31 AM, Thomas Kluyver <tho...@kluyver.me.uk> wrote: > > On Fri, Oct 20, 2017, at 12:15 PM, Donald Stufft wrote: >> Tell you what, I’ll drop everything today and write up a PEP... > > Donald, why are you so determined that this spec should n

Re: [Distutils] Entry points: specifying and caching

> On Oct 20, 2017, at 1:32 AM, Nick Coghlan wrote: > > 3. Unlike setup.cfg & pyproject.toml, actual humans never touch it - it's > written and read solely by software This is wrong BTW, humans can and do effectively write entry_points.txt, it’s a supported feature of

Re: [Distutils] Entry points: specifying and caching

> On Oct 20, 2017, at 7:02 AM, Nick Coghlan wrote: > > That's the one point where the "de facto standard" status of setuptools is > relevant to the question of whether the entry_points.txt format is a PyPA > interoperability standard: it is, because providing a

Re: [Distutils] Entry points: specifying and caching

> On Oct 20, 2017, at 1:32 AM, Nick Coghlan wrote: > > If we want to enable pytest plugin authors to use other build systems like > flit, then those build systems need a defined interoperability format that's > compatible with what pytest is expecting to see (i.e. entry

Re: [Distutils] Entry points: specifying and caching

> On Oct 19, 2017, at 5:26 PM, Tres Seaver wrote: > > Having the packaging > system register those services at installation time (even if it doesn't > care otherwise about them) seems pretty reasonable to me. It does register them at installation time, using an entirely

Re: [Distutils] Entry points: specifying and caching

> On Oct 19, 2017, at 4:36 PM, Thomas Kluyver <tho...@kluyver.me.uk> wrote: > > On Thu, Oct 19, 2017, at 09:04 PM, Donald Stufft wrote: >> Like I said, I’m perfectly fine documenting that if you add an >> entry_points.txt to the .dist-info directory, that is a

Re: [Distutils] Entry points: specifying and caching

> On Oct 19, 2017, at 4:04 PM, Donald Stufft <don...@stufft.io> wrote: > > Like I said, I’m perfectly fine documenting that if you add an > entry_points.txt to the .dist-info directory, that is an INI file that > contains a section named “console_scripts” and define

Re: [Distutils] Entry points: specifying and caching

> On Oct 19, 2017, at 3:55 PM, Thomas Kluyver <tho...@kluyver.me.uk> wrote: > > On Thu, Oct 19, 2017, at 08:29 PM, Donald Stufft wrote: >> Because it is? A generic plugin mechanism is not a packaging feature any >> more then a HTTP client is a packaging feature,

Re: [Distutils] Entry points: specifying and caching

> On Oct 19, 2017, at 3:15 PM, Thomas Kluyver <tho...@kluyver.me.uk> wrote: > > On Thu, Oct 19, 2017, at 08:01 PM, Donald Stufft wrote: >> >>> On Oct 19, 2017, at 2:54 PM, Thomas Kluyver <tho...@kluyver.me.uk >>> <mailto:tho...@kluyver.me.

Re: [Distutils] Entry points: specifying and caching

> On Oct 19, 2017, at 2:54 PM, Thomas Kluyver wrote: > > I don't think this needs to be controversial. They are a de-facto > packaging standard, whether or not that's theoretically necessary. > There's more than one tool that can create them (setuptools, flit), and > more

Re: [Distutils] Entry points: specifying and caching

> On Oct 19, 2017, at 2:28 PM, Paul Moore wrote: > > While I agree with this, one thing I have noticed with recent work is > that standardising existing things has typically been relatively > painless and stress-free. But designing new mechanisms generally ends > up with

Re: [Distutils] Entry points: specifying and caching

> On Oct 19, 2017, at 12:14 PM, Thomas Kluyver <tho...@kluyver.me.uk> wrote: > > On Thu, Oct 19, 2017, at 04:10 PM, Donald Stufft wrote: >> I’m in favor, although one question I guess is whether it should be a a >> PEP or an ad hoc spec. Given (2) it should *

Re: [Distutils] Entry points: specifying and caching

> On Oct 18, 2017, at 10:52 AM, Thomas Kluyver wrote: > > > 1. Specification > I’m in favor, although one question I guess is whether it should be a a PEP or an ad hoc spec. Given (2) it should *probably* be a a PEP (since without (2), its just another file in the

Re: [Distutils] Extracting distutils into setuptools

> On Oct 1, 2017, at 1:53 PM, xoviat wrote: > > After thinking again about that possibilities that we've discussed here, I > realized that a previously proposed alternative would eliminate external > build-time dependencies and allow us to merge setuptools with distutils:

Re: [Distutils] Extracting distutils into setuptools

if for the Gilectomy fork): > > "Second, as you hack on the Gilectomy you may break your "python" executable > rather badly. This is of course expected. However, the python Makefile itself > depends on having a working local python interpreter, so when you break that

Re: [Distutils] Extracting distutils into setuptools

> On Sep 30, 2017, at 3:52 PM, xoviat wrote: > > I don't think CPython needs to bundle all of its build-time dependencies. > That principle doesn't really apply to other Python programs nor most other > programs in general. AFAIK, CPython already has a build-time dependency

Re: [Distutils] Extracting distutils into setuptools

> On Sep 29, 2017, at 11:21 PM, xoviat wrote: > > I don't think writing shims for distutils is as easy as you make it sound. In > fact, I'd venture to say that it's an intractable problem because of the > difficulty of knowing the number of distutils hacks that are in the

Re: [Distutils] Extracting distutils into setuptools

> On Sep 29, 2017, at 5:16 PM, Steve Dower wrote: > > I'm happy enough with this approach, my only problem with it is that I don't > want to be maintaining two versions (the new one that we want people to > change to, and the old one so that people keep working with

Re: [Distutils] Extracting distutils into setuptools

> On Sep 29, 2017, at 2:31 AM, Nick Coghlan wrote: > > This is one of those changes where the longer term process improvement > benefits are already reasonably clear to the folks involved in > maintaining the software (i.e. we think it will provide a better end > user

Re: [Distutils] Extracting distutils into setuptools

On Sep 27, 2017, at 5:37 AM, Nick Coghlan wrote: > > pip's trick of injecting setuptools into a process to change the > behaviour of distutils imports continues to work I suspect this might be difficult, but I haven’t actually tried it. Our trick (and really setup tools

Re: [Distutils] string types for paths in PEP 517

> > On Sep 5, 2017, at 4:36 AM, Nathaniel Smith wrote: > > Does pip in fact use /tmp for temporary directories? (It's not always > the right choice, because /tmp has limited space on some systems, e.g. > b/c it's on a ramdisk. If we still had build_directory= then this > could

Re: [Distutils] PEP 517 again

ild their packages? Not that I am aware of. > > I tried to do that with conda-packages, and failed due to pip's caching > behavior-- it probably would have worked fine in production, but when I was > developing the build script, I couldn't reliably get pip to ignore cached >

Re: [Distutils] PEP 517 again

> On Sep 1, 2017, at 12:23 AM, Nick Coghlan wrote: > > 1. Wheel download cache (if this gets a hit, don't even check the package > repo) > 2. Check the package repo for a wheel file (and if you find one, add > it to the download cache) > 3. Local build cache (make this

Re: [Distutils] PEP 517 again

> On Aug 31, 2017, at 12:58 PM, Chris Barker <chris.bar...@noaa.gov> wrote: > > In fact, I see PEP 517 as a step toward more wheels, and fewer sdists for > distribution. Everything should ideally still have a sdist. — Donald Stufft ___

Re: [Distutils] PEP 517 again

le. Another possible solution is to stop using the wheel tagging format to encode this information for pip’s internal wheel cache and to encode it into the path, so that instead of having PyPy and CPython share a cache directory, they each have their own. That isn’t an unreasonable me

Re: [Distutils] PEP 517 again

e should be spending a whole lot of time or effort trying to support. Two copy/pasteable lines of code is a tiny price to pay. I haven’t talked to Nick, but I’d be surprised if he was against this, since it’s basically what he wanted with a more specific ex

Re: [Distutils] PEP 517 again

> On Aug 28, 2017, at 3:58 PM, Paul Moore <p.f.mo...@gmail.com> wrote: > > On 28 August 2017 at 20:47, Donald Stufft <don...@stufft.io> wrote: >> I also believe it is fundamentally impossible for the backends to guarantee >> consistency if they have a separat

Re: [Distutils] PEP 517 again

it works to say “You *must* ensure a consistent output, and I think the only thing we can do is say that you *SHOULD* try to be consistent, and leave it up to front ends to decide how seriously they take that as a requirement. — Donald Stufft ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] PEP 517 again

> On Aug 28, 2017, at 12:29 PM, Chris Barker <chris.bar...@noaa.gov> wrote: > > On Mon, Aug 28, 2017 at 9:21 AM, Donald Stufft <don...@stufft.io > <mailto:don...@stufft.io>> wrote: >> Donald, what do you think? IIRC, you were most keen on going >> sdis

Re: [Distutils] PEP 517 again

c exception it at least prevents bubbling up unrelated errors and having them be treated as asking for the fallback behavior if possible. — Donald Stufft ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] PEP 517 again

ckends: > > class DistutilsUnsupportedOperation(RuntimeError): > pass > > and then put UnsupportedOperation in the "distutils" library in 3.7, with an > eventual move to that. It's not pretty but there have been plenty of hacks > for backwards compatibility so far (i

Re: [Distutils] PEP 517 again

The thing being bubbled up is a backend accidentally calling an API that has yet to be implemented (an error that should be reported) being bubbled up and erroneously handled as the backend reporting it doesn't support making a sdist (not an error, son no traceback). Sent from my iPhone > On

Re: [Distutils] PEP 517 again

as son as we know it’s going to fail. — Donald Stufft ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] PEP 517 again

thon interpreter to fix our weirdness that is going to happen. — Donald Stufft ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] PEP 517 again

andle this case” not “I’ve accidentally called some code that wasn’t implemented yet”. The use case is almost exactly the same as the binop use case. — Donald Stufft ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] PEP 517 again

icate that the real implementation still needs to be added.” This is not a case of some real implementation not having yet been added or some stub code getting called before it’s ready. This use case more closely resembles NotImplemented. — Donald Stufft ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

  1   2   3   4   5   6   7   8   9   10   >