[Distutils] Re: pip and missing shared system system library

On Thu, Aug 6, 2020 at 3:06 PM David Mathog wrote: > > On Thu, Aug 6, 2020 at 11:54 AM Nathaniel Smith wrote: > > > If the code that failed to give a good error message is in > > louvain-igraph, then you should probably talk to them about that :-). > > There's no

[Distutils] Re: pip and missing shared system system library

On Thu, Aug 6, 2020 at 11:39 AM David Mathog wrote: > Looking at the setup.py for louvain here: > > https://github.com/vtraag/louvain-igraph/blob/master/setup.py > > around line 491 is the code for pkg-config and the "core" message . > It looks like it should exit when pkg-config failed, and

[Distutils] Re: Archive this list & redirect conversation elsewhere?

On Tue, Aug 4, 2020 at 4:13 PM Oscar Benjamin wrote: > What I haven't quite got my head around is: what exactly is the > "workflow" with discourse if you are a regular follower/contributor on > some forum? > > Do people who use it a lot begin by going to the forum website? > > Do they get the

[Distutils] Fwd: Re: psycopg2/psycopg2-binary

Can a mod please disable this person's subscription to distutils-sig...? -- Forwarded message - From: Date: Sat, Apr 6, 2019 at 3:16 PM Subject: Re: [Distutils] Re: psycopg2/psycopg2-binary To: [image: BitBounce] Thanks for emailing me! No, I haven’t been hacked :) I

[Distutils] Re: psycopg2/psycopg2-binary

On Sat, Apr 6, 2019 at 2:14 PM Bert JW Regeer wrote: > > Hey all, > > You may have seen some hub hub around psycopg2 and no longer shipping binary > wheels by default [1][2] (and in fact using psycopg2-binary if you want > wheels), and I wanted to bring it up here because it demonstrates a

[Distutils] Re: PEP idea regarding non-glibc systems

conf-based build systems. > > -- End of forwarded message - > > Alpine guys doesn't seem to use any specific build flags, though > find_library function was customized: > https://git.alpinelinux.org/aports/tree/main/python3 > > > On Mon, Feb 25, 2019 at 10:48

[Distutils] Re: PEP idea regarding non-glibc systems

gt; > out to be pretty useless – it's empty on Alpine (or parsing code is > > buggy). If ".interp" field is not available, then interpreter is > > statically linked :) > > > > 4. If any glibc-specific functionality is needed at this point, code > > fro

[Distutils] Re: PEP-582 concerns

On Wed, Feb 20, 2019 at 8:49 AM Steve Dower wrote: > > On 20Feb2019 0831, Nathaniel Smith wrote: > > Yeah, __pypackages__ has no way to handle scripts, and also no way to > > access packages when you're running from a directory. Pipenv already > > handles both of these

[Distutils] Re: PEP-582 concerns

On Wed, Feb 20, 2019, 08:13 Dan Ryan wrote: > I don’t have a ton of concern with regard to pipenv. We already just jump > through hoops to modify paths and such at runtime, this honestly sounds > like a cleaner approach. Obviously we won’t actually get to clean up the > code for a long time but

[Distutils] Re: PEP-582 concerns

I'd caution against folks getting too worked up about PEP 582. I know it's been getting a lot of attention on social media recently, but, it's a draft that hasn't even been submitted for discussion yet. Most PEPs at this stage never end up going anywhere. And in general, when people start digging

[Distutils] Re: PEP idea regarding non-glibc systems

On Tue, Feb 19, 2019 at 3:28 PM Alexander Revin wrote: > > Hi all, > > I have an idea regarding Python binary wheels on non-glibc platforms, > and it seems that initially I've posted it to the wrong list ([1]) > > Long story short, the proposal is to use platform tuples (like > compiler ones) for

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

On Tue, Jan 29, 2019 at 4:11 PM Dan Ryan wrote: > > In the ideal future would we avoid the build step by having PyPI host > primarily wheels? In which case anything available on PyPI would hopefully > have its metadata exposed on the JSON endpoint and we could sidestep that. > > Either way we

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

On Tue, Jan 29, 2019, 06:59 Donald Stufft 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

[Distutils] Re: Idea: perennial manylinux tag

On Sun, Dec 2, 2018 at 6:10 PM Robert T. McGibbon wrote: > I suspect that *I* am one of the major reasons that the manylinux1 -> > manylinux2010 transition has been unreasonably drawn out, rather than any > particular design flaw in the versioning scheme (manylinux_{cardinal number} > vs.

[Distutils] Re: Idea: perennial manylinux tag

On Fri, Nov 30, 2018 at 7:13 AM Thomas Kluyver wrote: > Do we lose the ability for a system to explicitly declare that it is or isn't > compatible with a given manylinux variant (via the _manylinux? Good question. Straw man: if _manylinux is importable, and _manylinux.manylinux_compatible is

[Distutils] Re: Idea: perennial manylinux tag

On Fri, Nov 30, 2018 at 7:35 AM Paul Moore wrote: > Only Linux users can really answer this. But what I will say is that > on Windows, anything other than the core system libraries must be > bundled in the wheel (so, for example, Pillow bundles the various > image handling DLLs). Manylinux (as I

[Distutils] Re: Idea: perennial manylinux tag

On Fri, Nov 30, 2018 at 10:29 PM Paul Moore wrote: > > On Sat, 1 Dec 2018 at 04:42, Nathaniel Smith wrote: > > How does this affect spec-writing? Well, we want to allow for non-pip > > installers, so the part that pip does has to be specified. But pip's > > part i

[Distutils] Re: Idea: perennial manylinux tag

complex cross-ecosystem coordination with new formal specs for each one; instead they'll be routine engineering problems for the docker image+auditwheel maintainers to solve. -n On Fri, Nov 30, 2018 at 12:09 AM Nathaniel Smith wrote: > > Hi all, > > The manylinux1 -> manylinux2010 transition

[Distutils] Re: Idea: perennial manylinux tag

Yes On Fri, Nov 30, 2018 at 1:27 AM Paul Moore wrote: > > On Fri, 30 Nov 2018 at 09:22, Pradyun Gedam wrote: > > > > > > On Fri, 30 Nov 2018 at 1:42 PM, Nathaniel Smith wrote: > >> > >> April 2018: PEP 517 accepted > > > > > > I think

[Distutils] Idea: perennial manylinux tag

Hi all, The manylinux1 -> manylinux2010 transition has turned out to be very difficult. Timeline so far: March 2017: CentOS 5 went EOL April 2018: PEP 517 accepted May 2018: support for manylinux2010 lands in warehouse November 2018: support lands in auditwheel, and pip master December 2018: 21

[Distutils] Re: __pypackages__ discussion (was Re: Notes from python core sprint on workflow tooling)

On Sun, Sep 30, 2018 at 2:25 PM, Chris Jerdonek wrote: > [Splitting off a new thread for this question even if it might not > result in a discussion] > > On Sun, Sep 30, 2018 at 10:00 AM Dan Ryan wrote: >> >> Anyway, this is all a good discussion to have and I really appreciate you >> kicking

[Distutils] Notes from python core sprint on workflow tooling

Now that the basic wheels/pip/PyPI infrastructure is mostly functional, there's been a lot of interest in improving higher-level project workflow. We have a lot of powerful tools for this – virtualenv, pyenv, conda, tox, pipenv, poetry, ... – and more in development, like PEP 582 [1], which adds a

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

On Mon, Sep 17, 2018, 08:25 Antoine Pitrou wrote: > Hi, > > According to recent messages, it seems manylinux2010 won't be ready soon. > However, the baseline software in manylinux1 is becoming very old. As an > example, a popular C++ library (Abseil - https://abseil.io/) requires a > more recent

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

On Mon, Sep 17, 2018, 18:51 Joni Orponen wrote: > On Mon, Sep 17, 2018 at 6:07 PM Antoine Pitrou wrote: > >> Paul Moore wrote: >> > I'm not really familiar with manylinux1, but I'd be concerned if we >> > started getting bug reports on pip because we installed a library that >> > claimed to be

[Distutils] Re: SEC: Spectre variant 2: GCC: -mindirect-branch=thunk -mindirect-branch-register

On Wed, Sep 12, 2018, 12:29 Joni Orponen wrote: > On Wed, Sep 12, 2018 at 8:48 PM Wes Turner wrote: > >> Should C extensions that compile all add >> `-mindirect-branch=thunk -mindirect-branch-register` [1] to mitigate the >> risk of Spectre variant 2 (which does indeed affect user space

[Distutils] Re: Adopting virtualenv package maintenance

On Fri, Sep 7, 2018, 14:41 Tzu-ping Chung wrote: > > Just want to mention that adding activate_this.py to venv has been > proposed, and rejected. > https://bugs.python.org/issue21496 > Looks like the reason for the rejection was just that the submitter didn't provide a good rationale. If this

[Distutils] Re: Adopting virtualenv package maintenance

On Fri, Sep 7, 2018, 10:48 Brett Cannon wrote: > > > On Thu, 6 Sep 2018 at 13:44 Alex Becker wrote: > >> Another +1 to the utility of a maintainer. I am also working on package >> management and have found that venv is not a full replacement for >> virtualenv--for example I don't believe the

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

On Tue, Sep 4, 2018, 07:42 Nick Coghlan wrote: > On Tue, 4 Sep 2018 at 20:30, Nathaniel Smith wrote: > > > > On Mon, Sep 3, 2018 at 4:51 PM, Nick Coghlan wrote: > > > On Mon., 3 Sep. 2018, 5:48 am Ronald Oussoren, > > > > wrote: > > >> >

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

On Mon, Sep 3, 2018 at 4:51 PM, Nick Coghlan wrote: > On Mon., 3 Sep. 2018, 5:48 am Ronald Oussoren, > wrote: >> >> >> What’s the problem with including GPU and non-GPU variants of code in a >> binary wheel other than the size of the wheel? I tend to prefer binaries >> that work “everywhere",

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

On Tue, Sep 4, 2018 at 3:10 AM, Paul Moore wrote: > There's very much an 80-20 question here, we need to avoid letting the > needs of the 20% of projects with unusual needs, complicate usage for > the 80%. On the other hand, of course, leaving the specialist cases > with no viable solution also

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

On Thu, Aug 30, 2018 at 6:52 PM, Brett Cannon wrote: > > > On Thu, 30 Aug 2018 at 11:21 Nathaniel Smith wrote: >> >> If we're going to rethink this, > > > Well, I didn't want to "rethink" so much as "fill in". :) > >> >> the

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

not require >> f-strings. The tag only has to tell you which wheel is most likely to work. >> >> No sdist or wheel is ever guaranteed to work, for any number of reasons. >> >> On Aug 30, 2018 11:25, "Nick Coghlan" wrote: >> >> On Thu, 30 Aug 2018 at 0

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

On Thu, Aug 30, 2018, 08:23 Nick Coghlan wrote: > On Thu, 30 Aug 2018 at 09:58, Brett Cannon wrote: > > On Wed, 29 Aug 2018 at 15:54 Nathaniel Smith wrote: > >> This is a tricky decision. Any time a new Python comes out, some > >> existing wheels will cont

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

On Wed, Aug 29, 2018 at 10:25 AM, Brett Cannon wrote: > > > On Wed, 29 Aug 2018 at 01:56 Nathaniel Smith wrote: >> >> On Tue, Aug 28, 2018 at 11:46 AM, Brett Cannon wrote: >> > py36 >> > >> > py36-none-% but not py36-none-any: 2 (example) >>

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

On Tue, Aug 28, 2018 at 11:46 AM, Brett Cannon wrote: > py36 > > py36-none-% but not py36-none-any: 2 (example) > > py3 > > py3-none-% but not py3-none-any: 142 (example) Oh right, and these ones are totally sensible: this is the correct tag for a project that ships some vendored shared

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

On Tue, Aug 28, 2018 at 11:46 AM, Brett Cannon wrote: > cp36 > > %cp36-none-any.whl: 7 (example) > %cp36-none-%.whl: 70 (example) > cp36-none-%.whl but not cp36-none-any.whl: 65 (example that Nathaniel knows > very well ;) Yeah, that's an old hack that never got removed, and causes problems:

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

I think the answer to all of these questions is "well, no-one's ever really looked that closely". There's a theory behind the tags; they're supposed to be a reasonably expressive language for talking about Python dialect compatibility, Python C ABI compatibility, and platform ABI compatibility,

[Distutils] Re: Packaging Advice for EFF's Certbot

On Thu, Jul 26, 2018, 05:48 Ben Finney via Distutils-SIG < distutils-sig@python.org> wrote: > Brad Warren writes: > > > Our main use case has been the long tail of individuals or small teams > > of sysadmins who maintain servers and need or want help and automation > > around maintaining a

[Distutils] Re: Packaging Advice for EFF's Certbot

On Tue, Jul 24, 2018 at 5:48 PM, Brad Warren wrote: > Do you know if our approach to using setuptools entry_points to find plugins > will work [with conda]? This is described at > https://setuptools.readthedocs.io/en/latest/setuptools.html#dynamic-discovery-of-services-and-plugins. Yes,

[Distutils] Re: Packaging Advice for EFF's Certbot

On Mon, Jul 23, 2018 at 4:31 PM, Brad Warren wrote: > Hi! > > I work at the Electronic Frontier Foundation on Certbot which is the most > popular end user application for obtaining and installing SSL/TLS > certificates from Let’s Encrypt. Over the past few years, distributing > Certbot has been

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

On Fri, Jul 20, 2018 at 5:01 PM, Brett Cannon wrote: > I have updated PEP 518: > https://github.com/python/peps/commit/af73627e587c25b9ac6f28a0fda01953252df391#diff-f068c801ccb40fad40c0436ff1e25e3f LGTM. Thanks Brett! -n -- Nathaniel J. Smith -- https://vorpus.org -- Distutils-SIG mailing

[Distutils]Re: The Wheel specification and compatibility tags on Windows

The promise behind the limited ABI is exactly that if your extension works on 3.x, it will also work on 3.y, for y >= x. One thing to watch out for: normally extension modules on Linux and MacOS don't try to link to libpython. Instead they trust that someone else will make sure they only get

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

On Mon, Jul 16, 2018 at 11:27 AM, Donald Stufft wrote: > > 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

[Distutils]Re: pypi/twine complains about license

PyPI is not the license police. You can specify any license you like in the dedicated, free-form text, "license" field. That's the "license" field. But, PyPI does require that values in the "classifiers" field have to be taken from a known set. Among other things, this prevents typos, and

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

On Sat, Jul 7, 2018 at 3:41 AM, Paul Moore wrote: > On 30 June 2018 at 06:33, Nick Coghlan wrote: >> On 28 June 2018 at 11:37, Nathaniel Smith wrote: >>> So my inclination is to plan on ending up with build-system.requires >>> defaulting to ["setuptools"

[Distutils]Re: Handing over default BDFL-Delegate responsibilities for packaging interoperability PEPs to Paul Moore

Nick, thanks so much for your service in an often thankless job. It is appreciated! And Paul, thanks for taking this on! On Fri, Jul 6, 2018, 19:08 Nick Coghlan wrote: > Hi folks, > > Since 2013, I've been the default BDFL-Delegate for packaging > interoperability PEPs. In that time, the Python

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

On Thu, Jun 28, 2018 at 11:19 AM, Paul Moore wrote: > On 28 June 2018 at 18:45, Bernat Gabor wrote: >> In the pep it's stated tools can use the tool section >> https://www.python.org/dev/peps/pep-0518/#id28 and at no point says build >> tools only. So I don't think at all strange that towncrier

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

On Wed, Jun 27, 2018 at 2:25 PM, Paul Moore wrote: > On 27 June 2018 at 22:09, Pradyun Gedam wrote: >> >> On Wed, Jun 27, 2018 at 9:15 PM Paul Moore wrote: >>> >>> On 27 June 2018 at 15:59, Pradyun Gedam wrote: > >>> > >>> > Assuming we are going to disallow missing build-requires, >>> > I

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

On Wed, Jun 27, 2018 at 8:00 AM, Pradyun Gedam wrote: > > On Sun, Jun 24, 2018 at 10:50 AM Nathaniel Smith wrote: >> >> To go a bit against the grain here, I think at this point I'd suggest >> that if "build-system.requires" is missing, it should be silentl

[Distutils]Re: Possible change to PEP 517: look up the backend as $BACKEND.__build_backend__?

On Sun, Jun 24, 2018 at 12:47 AM, Thomas Kluyver wrote: > On Sun, Jun 24, 2018, at 7:19 AM, Nathaniel Smith wrote: >> What do you think? (Thomas, I'd love your thoughts in particular :-).) > > I agree that it looks nicer, but I'm not sure that it's worth the added > co

[Distutils]Possible change to PEP 517: look up the backend as $BACKEND.__build_backend__?

Hi all, I had a thought for something that might be a simple way to improve dev experience with custom build backends. A PEP 517 build backend is a Python object that has some special methods on it. And the way a project picks which object to use, is via pyproject.toml: [build-system]

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

To go a bit against the grain here, I think at this point I'd suggest that if "build-system.requires" is missing, it should be silently treated as if it had been set to ["setuptools", "wheel"]. Reasoning: - Implementing this should require only a trivial amount of code, now and in the long run.

[Distutils][ANN] Python 3.7 now available in the manylinux docker images

Hi all, Thanks to Emanuele Gaifas [1], the manylinux docker images now include Python 3.7 (currently the rc1 release), so if you want you can now start building and uploading wheels for 3.7 ahead of its expected release on June 27 [2]. -n [1] https://github.com/pypa/manylinux/pull/196 [2]

[Distutils] Re: Python 3.7 binary wheels

On Fri, May 11, 2018 at 12:10 PM, Lele Gaifax wrote: > Thank you Nathaniel, > > AFAICT current manylinux1 image still does not carry Python 3.7: is there an > ETA for that to happen? The ETA is whenever someone submits a working PR :-). -n -- Nathaniel J. Smith --

[Distutils] Re: Python 3.7 binary wheels

On Tue, May 8, 2018 at 7:35 PM, Steve Dower <steve.do...@python.org> wrote: > On 08May2018 2134, Nathaniel Smith wrote: >> for 3.6 there was a last minute problem >> with the Windows ABI that only got discovered during the rc period. But >> if you're willing to ke

[Distutils] Re: Python 3.7 binary wheels

On Tue, May 8, 2018, 20:59 Lele Gaifax wrote: > Hi all, > > Python 3.7 is steadily approaching its final release and I start wondering > > a) when will be the right time to start uploading 3.7 binary wheels on > PyPI? > The ABI was frozen at 3.7b3 (we're currently at b4),

Re: [Distutils] How to eliminate on part of a package?

If you're lazy, you could distribute the server package to everyone and just make sure that if someone tries to import it on python 2 then they get a useful error. On Thu, Apr 26, 2018 at 9:17 AM, Skip Montanaro wrote: > Yeah, splitting client and server packages is on

Re: [Distutils] providing a way for pip to communicate extra info to users

>From the TUF perspective it seems like it would be straightforward to make the MOTD a "package", whose "contents" is the MOTD text, and that we "upgrade" it to get the latest text before displaying anything. -n On Thu, Apr 12, 2018, 05:10 Nick Coghlan wrote: > On 12 April

Re: [Distutils] providing a way for pip to communicate extra info to users

On Mon, Apr 9, 2018, 16:47 Chris Jerdonek wrote: > > One of Donald's comments in response to the idea (and that occurred to > me too and that I agree with) is that providing a way to communicate > messages to users introduces another possible avenue for attack. I

Re: [Distutils] Removing wheel signing features from the wheel library

Even if no maintenance were required, it's still a feature that promises to provide security but doesn't. This kind of feature has negative value. I'd also suggest adding a small note to the PEP documenting that the signing feature didn't work out, and maybe linking to Donald's package signing

Re: [Distutils] new stuff overview, beta next week, user tests, & other Warehouse updates

On Tue, Mar 13, 2018 at 11:39 PM, Sumana Harihareswara wrote: > I've started preparing a > draft overview of what's new in PyPI/packaging/distribution to publicize > along with the beta; it says "not to be publicized" but I'll let you in on > the secret early. Maybe something

Re: [Distutils] /etc files

Note that this will make it impossible to distribute wheels of your package or to install it into a virtualenv, because those don't have an /etc. So it's mostly only suitable for projects that you use internally under a known and restricted set of deployment options, not for anything distributed

Re: [Distutils] Invalid Packages

On Fri, Feb 16, 2018 at 2:39 PM, Matt Gieger wrote: > I would like to see a clause added to the "Ivalid Package" section of PEP541 > that allows some mechanism for other pypi users to mark a package as spam. > Every day i see more spam packages added to pypi and currently

Re: [Distutils] Installed Extras Metadata

On Fri, Jan 26, 2018 at 8:37 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 27 January 2018 at 13:46, Nathaniel Smith <n...@pobox.com> wrote: >> >> The advantages are: >> >> - it's a simpler way to record information the information you want >> he

Re: [Distutils] draft PEP: manylinux2

On Mon, Feb 5, 2018 at 1:17 PM, Jonathan Helmus wrote: > Moving to GCC 5 and above will introduced the new libstd++ ABI. [1] The > manylinux2 standard need to define which ABI compiled libraries should be > compiled against as older version of libstdc++ will not support

Re: [Distutils] draft PEP: manylinux2

On Wed, Jan 31, 2018 at 4:01 PM, Mark Williams wrote: > Hi everyone! > > The manylinux1 platform tag has been tremendously useful, but unfortunately > it's showing its age: > > https://mail.python.org/pipermail/distutils-sig/2017-April/030360.html >

Re: [Distutils] PEP 508, environment markers & the possibility of Python 3.10

+1 to all of that. On Sat, Jan 27, 2018 at 9:44 PM, Nick Coghlan wrote: > Hi folks, > > In https://github.com/python/peps/issues/560, a user pointed out that > the current definition of python_version in PEP 508 assumes > single-digit major and minor version numbers: > >

Re: [Distutils] Installed Extras Metadata

On Fri, Jan 26, 2018 at 7:11 AM, Pradyun Gedam wrote: > Hello! I hope everyone's had a great start to 2018! :) > > A few months back, while working on pip, I had noticed an oddity about > extras. > > Installing a package with extras would not store information about the fact

Re: [Distutils] PEP 566 - metadata 1.3 changes

On Tue, Jan 16, 2018 at 8:55 PM, Nick Coghlan wrote: > The reason for *not* making PEP 566 a major version bump is in case > anyone actually implemented this draft requirement from PEP 426: > "Automated tools consuming metadata SHOULD warn if metadata_version is > greater than

Re: [Distutils] PEP 566 - metadata 1.3 changes

On Jan 12, 2018 8:00 AM, "Alex Grönholm" wrote: On the same note, wheel currently writes "2.0" as its metadata version. Shouldn't this be changed into 1.3 (along with ditching metadata.json)? Should wheel change to emit 1.3, or should the PEP change to become 2.0? I

Re: [Distutils] Or in version spec...

PEP 508 already allows parenthesized expressions with 'and' and 'or' for environment markers, so that's probably the most relevant prior art. I doubt '|' will be added at this point. On Dec 14, 2017 09:08, "Chris Barker - NOAA Federal" wrote: > > Sorry to lose the thread

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

On Wed, Dec 13, 2017 at 6:11 PM, Ivan Pozdeev via Distutils-SIG wrote: > > > On 14.12.2017 3:17, Barry Warsaw wrote: >> >> I'm about to release a new version of importlib_resources, so I want to >> get my flit.ini's require-python clause right. We support Python 2.7, >>

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

On Dec 5, 2017 08:42, "Dustin Ingram" wrote: Provides-Extra (optional, multiple use) ::: A string containing the name of an optional feature. Must be a valid Python identifier. May be used to make a dependency conditional on whether

Re: [Distutils] Entry points: specifying and caching

On Fri, Oct 27, 2017 at 5:34 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 27 October 2017 at 18:10, Nathaniel Smith <n...@pobox.com> wrote: >> >> On Thu, Oct 26, 2017 at 9:02 PM, Nick Coghlan <ncogh...@gmail.com> wrote: >> > Option 2: tempor

Re: [Distutils] Disabling non HTTPS access to APIs on PyPI

On Oct 27, 2017 11:49, "Alex Domoradov" wrote: RUN pip install --upgrade pip Try upgrading setuptools here too. -n ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Entry points: specifying and caching

On Thu, Oct 26, 2017 at 9:02 PM, Nick Coghlan wrote: > Option 2: temporary (or persistent) per-user-session cache > > * Pro: only the first query per path entry per user session incurs a linear > DB read > * Pro: given persistent cache dirs (e.g. XDG_CACHE_HOME, ~/.cache) even

Re: [Distutils] Entry points: specifying and caching

On Fri, Oct 20, 2017 at 11:59 PM, Nick Coghlan wrote: > Yeah, here's the gist of what I had in mind regarding the malware problem > (i.e. aiming to ensure we don't get all of setup.py's problems back again): > > - a package's own install hooks do *not* get called for that

Re: [Distutils] Entry points: specifying and caching

On Oct 19, 2017 11:10, "Donald Stufft" wrote: EXCEPT, for the fact that with the desire to cache things, it would be beneficial to “hook” into the lifecycle of a package install. However I know that there are other plugin systems out there that would like to also be able to do

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

On Tue, Sep 5, 2017 at 1:00 AM, Thomas Kluyver wrote: > I considered this. It's *potentially* a problem, but I think we should > not try to deal with it for now: > > - Normally, temp files will go in /tmp - so it should be fine to > construct paths of entirely ascii

Re: [Distutils] PEP 517 again

ship. So what's your plan for after you replace egg_info with prepare_metadata_for_build_wheel? Turning around and deleting the code you just wrote? -n > 2017-09-04 19:34 GMT-05:00 Nathaniel Smith <n...@pobox.com>: >> >> On Mon, Sep 4, 2017 at 5:09 PM, xoviat <xov...@gmail

Re: [Distutils] PEP 517 again

ist_info command, (b) there's some reason I'm missing why prepare_wheel_metadata matters, or (c) one of us is misunderstanding something :-). -n > 2017-09-03 21:00 GMT-05:00 Nathaniel Smith <n...@pobox.com>: >> >> On Sun, Sep 3, 2017 at 11:14 AM, xoviat <xov...@gmail.com> wro

Re: [Distutils] PEP 517 again

On Sun, Sep 3, 2017 at 11:14 AM, xoviat wrote: > Just an update for everyone here: > > 1. We're currently waiting on the implementation of the 'dist_info" command > in the wheel project. > 2. Once that is done we can switch pip over to reading dist-info rather than > egg_info. >

Re: [Distutils] PEP 517 again

On Fri, Sep 1, 2017 at 11:30 AM, Chris Barker wrote: > I'm still confused -- if setuptools ( invoked by pip) is producing > incorrectly named wheels -- surely that's a bug-fix/workaround that should > go into setuptools? > > If the build is being run by pip, then doesn't

Re: [Distutils] PEP 517 again

On Thu, Aug 31, 2017 at 8:41 AM, Chris Barker - NOAA Federal wrote: > The package manager should manage the package, not built it, or change it. > > Surely the build system should know how to correctly name the wheel it builds. It's probably worth mentioning the specific

Re: [Distutils] PEP 517 again

On Wed, Aug 30, 2017 at 9:56 PM, Nick Coghlan wrote: > On 31 August 2017 at 14:22, xoviat wrote: >> Again, let me repeat that: wheels generated using setuptools are valid for >> CPython only if build on CPython. This is not the current setuptools >> behavior

Re: [Distutils] PEP 517 again

On Mon, Aug 28, 2017 at 1:27 PM, Thomas Kluyver wrote: > On Mon, Aug 28, 2017, at 09:13 PM, Daniel Holth wrote: > > > Then end the debate by letting the PEP authors decide the return type, and > > write a paragraph explaining why the other options were rejected. It is not >

Re: [Distutils] PEP 517 again

On Sun, Aug 27, 2017 at 4:27 PM, Greg Ewing <greg.ew...@canterbury.ac.nz> wrote: > Nathaniel Smith wrote: >> >> - creating an sdist failed for unexpected reasons, that need a human >> to sort out (due to a broken system, or bugs – hey, they happen – or >> ...

Re: [Distutils] PEP 517 again

On Sat, Aug 26, 2017 at 6:30 PM, C Anthony Risinger <c...@anthonyrisinger.com> wrote: > On Aug 26, 2017 5:13 PM, "Nathaniel Smith" <n...@pobox.com> wrote: > > On Sat, Aug 26, 2017 at 1:47 PM, C Anthony Risinger > <c...@anthonyrisinger.com> wrote: > >

Re: [Distutils] PEP 517 again

On Sat, Aug 26, 2017 at 1:47 PM, C Anthony Risinger <c...@anthonyrisinger.com> wrote: > On Aug 26, 2017 2:17 PM, "Nathaniel Smith" <n...@pobox.com> wrote: >> >> [removed Guido from CC] >> >> On Aug 26, 2017 02:29, "Paul Moore" <p.f.m

Re: [Distutils] PEP 517 again

On Sat, Aug 26, 2017 at 2:06 PM, xoviat wrote: > I also think that Guido pretty much ruled out Notimplemented. As I've said, I don't think it matters a huge deal whether we use NotImplemented or not. But please don't treat Guido as some kind of pronouncement generating machine

Re: [Distutils] PEP 517 again

On Sat, Aug 26, 2017 at 12:54 PM, Paul Moore <p.f.mo...@gmail.com> wrote: > On 26 August 2017 at 20:17, Nathaniel Smith <n...@pobox.com> wrote: >> Eh... I would really prefer something that's (a) more explicit about what >> specifically went wrong, and (b) harder

Re: [Distutils] PEP 517 again

[removed Guido from CC] On Aug 26, 2017 02:29, "Paul Moore" wrote: On 26 August 2017 at 03:17, Guido van Rossum wrote: > In pretty much any other context, if you have an operation that returns an > regular value or an error value, the error value should

Re: [Distutils] Conditionless setup.py

On Fri, Aug 25, 2017 at 5:46 PM, xoviat wrote: > I personally do not understand the aversion to YAML. I mean yes, the > specification is more complicated, but it's also more popular and the YAML > files will not be complex enough for a C library to help that much. And > since

Re: [Distutils] Conditionless setup.py

On Fri, Aug 25, 2017 at 1:00 PM, Jeremy Stanley wrote: > (The > community around it is sensitive to gender diversity issues and > wants to avoid acquiring more of a "brogrammer" image, so some of us > worry that any conspicuous TOML files checked into revision control >

Re: [Distutils] PEP 517 again

On Fri, Aug 25, 2017 at 2:26 PM, xoviat wrote: >> I'm more or less persuaded by Nathaniel's argument that the source >> directory shouldn't be on sys.path > > I do too. There should be an option in pyproject.toml to disable this > behavior though so that numpy can build itself.

Re: [Distutils] PEP 517 again

d frontends would instead write: try: requires = backend.get_requires_for_build_sdist() except getattr(backend, "SdistBuildNotSupportedError", ()): invoke_fallbacks() That's also kind of awkward, but... could be worse? -n > 2017-08-25 16:13 GMT-05:00 Nathaniel Smith <n.

Re: [Distutils] PEP 517 again

On Fri, Aug 25, 2017 at 9:49 AM, Thomas Kluyver wrote: > Can I gently ask everyone involved to consider whether the > notimplemented/error discussion is verging into bikeshedding > (http://bikeshed.org/)? > > The technical arguments I have seen so far are: > - The exception

Re: [Distutils] PEP 517 again

On Fri, Aug 25, 2017 at 1:51 PM, Thomas Kluyver wrote: > On Fri, Aug 25, 2017, at 09:50 PM, xoviat wrote: > > > Genius! > > > 1% inspiration, 99% frustration :-P This joke is so clever that I fear we may be forced to implement the solution after all, just to punish Thomas.

Re: [Distutils] Fwd: Re: PEP 517 again

On Thu, Aug 24, 2017 at 9:17 PM, xoviat wrote: > > I'm *not* OK with banning in-tree builds in the spec, since that's > > both unnecessary and unenforceable > > Well then either we can trust the backend or we cannot. If we can, then this > is both necessary and enforceable. If

Re: [Distutils] PEP 517 again

On Thu, Aug 24, 2017 at 6:11 AM, Thomas Kluyver wrote: > Nathaniel seems to be busy with other things at the moment, so I hope he > won't mind me passing on this list of things he'd like to resolve with > the draft PEP. I'll quote his comments and put my responses inline.

  1   2   3   4   5   >