[Distutils] Re: Making setup.py run external command to build

On Fri, 26 Mar 2021, at 23:04, Julian Smith wrote: > I can't tell from pip-18.1's diagnostics what exactly is going wrong. > > Given that my setup.py implements the normal distutils-style argv > handling, i was expecting things to work, but pip-18.1 appears to fail > before it even tries to run

[Distutils] Re: Making setup.py run external command to build

On Thu, 25 Mar 2021, at 19:07, Julian Smith wrote: > I was a little surprised to find out that one can't use pip to create > an sdist, but i'm a bit late to this party and it looks like there's > been plenty of discussion about this in the past. There is now the (quite new) 'build' tool which can

[Distutils] Re: Making setup.py run external command to build

On Tue, 23 Mar 2021, at 11:13, Julian Smith wrote: > So as far as i can tell, there are two levels of abstraction at which > on can implement customised Python packaging (the setuptools.setup()'s > callbacks or the setup.py command line), but neither one seems to be > documented or standardised.

[Distutils] Re: multibuild failure

On Thu, 25 Feb 2021, at 09:56, Robin Becker wrote: > I looked into the manylinux image with docker and it seems that > manylinux no longer supports 2.7 can anyone confirm this? It looks like that's correct: https://github.com/pypa/manylinux/issues/428 The final comment there notes that: >

[Distutils] Re: Unsubscribing from this list

t; On 9/21/20 9:50 AM, Thomas Kluyver wrote: > > If it's not already the case, could someone configure the list so that only > > subscribers can send messages? > > > > If we've already got any obvious anti-spam measures like that in place, > > then I'm starting to

[Distutils] Re: Unsubscribing from this list

If it's not already the case, could someone configure the list so that only subscribers can send messages? If we've already got any obvious anti-spam measures like that in place, then I'm starting to agree that the signal to noise ratio has fallen too low. Of the 10 latest conversations in the

[Distutils] Re: Fwd: Re: Use of "python" shebang an installation error?

On Tue, 21 Jul 2020, at 21:50, David Mathog wrote: > ./lib/python3.6/site-packages/pip/_vendor/appdirs.py:#!/usr/bin/env python Python packaging tools like pip generally differentiate between *scripts*, which are installed to be run from the command line, and *modules*, which are imported from

[Distutils] Re: Development installation with pyproject.toml/poetry?

Hi Fredrik, You can do an editable install using whichever development tool you've chosen, e.g. Poetry. The poetry docs (https://python-poetry.org/docs/basic-usage/) say it does an editable install by default. Currently, there isn't a standardised way for 'frontend' tools like pip to ask for

[Distutils] Re: package management - common storage while keeping the versions straight

On Tue, 23 Jun 2020, at 23:51, David Mathog wrote: > What I am after is some method of keeping exactly one copy of each > package-version in the common area (ie, one might find foo-1.2, > foo-1.7, and foo-2.3 there), while also presenting only the one > version of each (let's say foo-1.7) to a

[Distutils] Re: The base docker images for manylinux appear to be private

OM quay.io/pypa/manylinux2010_centos-6-no-vsyscall > > We will build this image ourself. > > Best, > > > On Wed, Feb 26, 2020 at 10:38 AM Thomas Kluyver wrote: >> __ >> To be precise, these are not uploaded at all - there's no hidden repository >> on quay.io AFAICT,

[Distutils] Re: The base docker images for manylinux appear to be private

To be precise, these are not uploaded at all - there's no hidden repository on quay.io AFAICT, and I'm an owner of the pypa team there. The CI on the manylinux repo always builds both stages one after the other. They're split as an implementation detail - if I recall correctly, doing

[Distutils] Re: Keywords field in metadata: space separated or comma separated?

our guesses about how an index > would work; actually implementing the first version of PyPI wasn't a > part of Greg's project. > > Getting far enough along to build a range of C-based extensions was a > pretty substantial bootstrapping task in the late '90s! > > On Novembe

[Distutils] Keywords field in metadata: space separated or comma separated?

Hi all, The metadata specification shows the keyword field as a space separated list: https://packaging.python.org/specifications/core-metadata/#keywords PEP 566 backs that up, saying that the transformation to JSON should split that field on whitespace:

[Distutils] Re: Linux binary wheels?

You probably want to try 'repairing' the wheel with auditwheel to make a manylinux wheel from it: https://pypi.org/project/auditwheel/ On Wed, Aug 21, 2019, at 4:18 PM, Matthew Brett wrote: > Hi, > > Yes, here you are trying to upload a generic Linux wheel. PyPI > refuses, because there's no

[Distutils] Re: Linux binary wheels?

On Tue, Aug 20, 2019, at 3:50 PM, Brian Skinn wrote: > I wonder if there's an OS dependence here, though -- I'm almost certain I've > had to use `--only-binary` in the past, to avoid pip on my Windows machines > trying to download and build sdists, even when wheels were available. Possibly you

[Distutils] Re: Undesired publication of software project and personal data on PyPI

On Mon, May 27, 2019, at 9:55 AM, Richard Neumann wrote: > I do not wish to have my private software projects liked to my > company's email account, but have no means on contacting the publisher > on PyPI nor uploading an updated version of the package's metadata > since I am not the owner of the

[Distutils] Re: question about claiming potentially abandoned namespaces on PyPI

On Sun, May 19, 2019, at 11:08 PM, Pradyun Gedam wrote: > Thanks for reaching out. I suggest you file an issue at > https://github.com/pypa/warehouse for a PEP 541 request. That'll probably be > the best place. It looks like Warehouse issues are the de-facto standard place where people make

[Distutils] Re: question about claiming potentially abandoned namespaces on PyPI

Hi Emma, On Sun, May 5, 2019, at 12:49 AM, Emma Tosch wrote: > I have a project that I would like to post on PyPI that clashes with an > existing project that I believe may be abandoned I don't have the answers to your actual questions about who to contact. But have you seen the rather

[Distutils] Re: wrong SHA256 on setuptools

I think you've done SHA1 instead of SHA256. On Thu, Mar 21, 2019, at 5:27 PM, Martin Baker wrote: > The SHA256 listed for setuptools-40.8.0.zip is > 6e4eec90337e849ade7103723b9a99631c1f0d19990d6e8412dc42f5ae8b304d > > But the actual SHA sum is 3547552b1009283f7ae31fded32ad33ed160e671 > >

[Distutils] Re: Automatic and internal Pip package management system

Hi Pedro, I think I've seen some code that does this before, but I can't find it now. It's generally regarded as a crazy hack, and I wouldn't recommend anyone use it except as a joke/demo. Some of the reasons: 1. Downloading and running code from the internet if you mistype an import

[Distutils] Re: PEP 440 on fully autonomous forks versioning

On Fri, Mar 1, 2019, at 9:59 AM, Sofia Nunes wrote: > So, let’s assume I fork a package which is on version 2.1. and change its > name. > Would my distribution version be 1.0 or 2.2/3.0? Or none of the options? From a technical perspective, I don't think it matters: if your fork has a new name,

[Distutils] Re: Question on Python Package scanning

I forgot to mention that there is work/discussion about supporting code signing, in PEPs 458 and 480. But it's a complicated topic, and code signing is not the silver bullet that some commentators seem to think it is. On Fri, Feb 8, 2019, at 12:10 PM, Thomas Kluyver wrote: > On Thu, Feb 7, 2

[Distutils] Re: Question on Python Package scanning

On Thu, Feb 7, 2019, at 11:55 PM, Prateek Mohta wrote: > I wanted to check if the packages available on Pypi.org are scanned > for any security vulnerabilities or not, can you please confirm. As far as I know, they are not. > My concern is how do you control if someone uploads a malicious code >

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

On Tue, Jan 29, 2019, at 2:43 PM, Paul Moore wrote: > And when they start adding > version numbers to that (like the OP's package >= 10.0 @ > https://github.com/owner/package.git) I can't even begin to understand > what they think it might mean. I presume the idea is that it uses that repository

[Distutils] Re: PEP 517 - source dir and sys.path

On Sun, Jan 27, 2019, at 7:47 PM, Paul Moore wrote: > What is more difficult is the question of whether the PEP should > change. As Chris pointed out, the previous discussion ended up saying > that the build directory should not be on sys.path, but acknowledged > that mandating that might cause

[Distutils] Re: PEP 517 - source dir and sys.path

I haven't read those discussions in full (sorry to be lazy, but there's quite a lot there), but my initial take is that the rule doesn't apply to running setup.py scripts, where there's a greater need for backward compatibility. I think the rule about the CWD not being on sys.path only applies to

[Distutils] Re: Idea: perennial manylinux tag

I'll betray my lack of understanding of how ABIs work: PEP 571 (manylinux2010) defines a set of libraries besides libc which compatible wheels can safely link against, such as glib and libXrender. Most of these are only versioned by the filename suffix (like .so.6), while glibc and a few

[Distutils] Re: [poposal for preparing a pep] sharing package installations between virtualenvs

Have you tried using conda envs? Conda avoids duplication by unpacking all packages to a shared directory and then hard-linking them into environments. I'm not saying that should preclude doing something similar for virtualenvs, but it's probably worth looking at existing solutions before

[Distutils] Re: Notes from python core sprint on workflow tooling

On Sun, Sep 30, 2018, at 2:35 PM, Paul Moore wrote: > Personally, I think that the toolkit approach (standards, interop, low > level support) is where distutils-sig and PyPA works best. Higher > level unifications ("one tool to rule them all") have historically > been much less successful. I

[Distutils] Re: setuptools configuration in pyproject.toml

On Tue, Sep 25, 2018, at 9:13 AM, Paul Moore wrote: > I personally don't see much advantage in the "dump everything in one > file" philosophy. so from a personal POV I'd prefer setuptools' config > to remain in setup.cfg, but if they have reasons for wanting to move, > the PEP allows them that

[Distutils] Re: disable building wheel for a package

On Fri, Sep 14, 2018, at 4:26 PM, Paul Moore wrote: > I don't think it's "hard to predict". I *do* think it's badly documented/not > standardised. > ... > Better would be to have a supported library that exposes the logic pip > uses (or as I said above, the standard-defined logic) to determine >

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

On Tue, Sep 18, 2018, at 10:02 AM, Antoine Pitrou wrote: > Nathaniel Smith wrote: > > It's naughty, you shouldn't do it, and the energy you put into making > > pseudo-manylinux1 wheels could probably be better put into making finishing > > up the manylinux2010 work – there's not that much to do. >

[Distutils] Re: Should an sdist/MANIFEST.in include docs and tests?

On Mon, Sep 10, 2018, at 1:06 PM, Ian Stapleton Cordasco wrote: > It seems silly that we're not also considering the portions of the > world with terrible internet when making this decision. Giant sdists > make their lives orders of magnitude worse for the benefit of maybe > 20-30 people who tend

[Distutils] Re: Should an sdist/MANIFEST.in include docs and tests?

On Mon, Sep 10, 2018, at 12:33 AM, Bert JW Regeer wrote: > Speaking as a maintainer of various different packages for the Pylons > project, we include the following in our sdists:> > - source code for the package > - tests for the package > - documentation for the package > > and of course the

[Distutils] Re: Clarification on string arguments in PEP 517 hooks

On Mon, Aug 20, 2018, at 2:52 PM, Paul Moore wrote: > The various hooks take directory paths as arguments, and typically > return a filename (e.g., build_wheel). The returned filename is always > explicitly noted as being *a unicode string*. However, argumnents > (metadata_directory in

[Distutils] Re: Timestamp of installed files

On Sat, Aug 4, 2018, at 9:34 AM, Paul Moore wrote: > Whether timestamps are > preserved by the wheel building process depends on the build system - > so the question boils down to "does setup.py bdist_wheel preserve > timestamps?" in the case of the setuptools backend - which is really a >

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

Hi all, Do we know of any tool that can, given the name of one or more packages, follow dependency chains and produce a list of packages in the order they need to be installed, assuming every package needed will be built from source? Running "pip download --no-binary :all: ipython" gets me a

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

On Mon, Jul 16, 2018, at 11:50 AM, Paul Moore wrote: > On 16 July 2018 at 11:05, Thomas Kluyver wrote: > > My proposal was 2a ;-). And that's still my inclination, as we've got > > examples of people using pyproject.toml for unrelated purposes that > > shouldn't affect how

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

On Mon, Jul 16, 2018, at 11:02 AM, Paul Moore wrote: > My inclination would be to recommend 2b. I said that before checking > whether that was your proposal or Nathaniel's ;-), and it's based > mostly on gut feel and "that's what pip does now and I don't see any > reason to change it" though. My

[Distutils]Re: pypi/twine complains about license

On Thu, Jul 12, 2018, at 8:19 AM, Robin Becker wrote: > The previous > answer says there is a list so I can use that. I don't think anyone linked to it yet, so: https://pypi.org/pypi?%3Aaction=list_classifiers -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an

[Distutils]Re: pypi/twine complains about license

On Wed, Jul 11, 2018, at 7:32 PM, Chris Jerdonek wrote: > And yet you can see "License: ReportLab BSD Derived" in the left-hand > column under "Meta," so how did it get there? Did PyPI previously fall > back to including the "License" classifier value as is (even if > invalid) if no "license"

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

To echo Nathaniel, thanks Nick; in the time I've been on this list, I think you've done an impressive job of moderating discussions, ensuring we can reach consensuses and move forwards. And thanks Paul for stepping up to fill this role. :-) On Sat, Jul 7, 2018, at 4:15 AM, Nathaniel Smith wrote:

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

On Thu, Jun 28, 2018, at 6:27 PM, Brett Cannon wrote: > The file was originally meant to target building wheels for libraries. > It just happens that folks have pushed that out to include apps as > well. So if the purpose of the file expands to include apps as well > then that changes what the PEP

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

On Thu, Jun 28, 2018, at 8:25 AM, Paul Moore wrote: > I can see the practicality argument here. I don't think (correct me if > I'm wrong!) that anyone particularly anticipated when we were drafting > PEP 518 that the tools section would be used by anything other than > build tools - I know I

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

On Sun, Jun 24, 2018, at 9:30 AM, Nathaniel Smith wrote: > (What does 'flit init' do if someone already has a pyproject.toml, by the > way?) At present, it prompts you to overwrite it or cancel. I guess that will need to change at some point as more tools use pyproject.toml. -- Distutils-SIG

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

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 complexity: is 'flit' equivalent to 'flit.__build_api__' (i.e. from flit import

[Distutils] Re: PyPI not showing latest version?

Since the old PyPI was shut down, I have noticed that it takes a few minutes for new package updates to show up. I assume that the new site is more heavily cached. On Wed, Jun 13, 2018, at 4:01 PM, Vinay Sajip via Distutils-SIG wrote: > I just uploaded python-gnupg 0.4.3 to PyPI using Twine.

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

On Thu, May 31, 2018, at 4:39 PM, Matthias Klose wrote: > It's on the path by default in Debian and Ubuntu, only for new users > (~/.profile). Thanks, that's good to hear. I realise it's been a couple of years since I set up a fresh Linux installation. Upgrades are working too well! --

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

On Fri, May 25, 2018, at 6:58 PM, Wes Turner wrote: > ~/.local/bin is user-writeable. If ~/.local was on PATH or by default, > it could potentially preempt/modify the behavior of system libraries > and binaries; which is a security risk. I've heard this argument before, and it doesn't stand up,

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

On Fri, May 25, 2018, at 5:11 PM, Victor Stinner wrote: > As an user, I want to use "sudo pip install" because packages > installed in /usr (or /usr/local) are accessible without having to > touch PYTHONPATH: the install directory is part of the default > sys.path. This is also true for "pip

[Distutils] Re: org-mode README file formats

On Wed, May 9, 2018, at 7:22 PM, Diane Trout wrote: > Does the warehouse actually read the readme file directly? or does it > preferentially look at long_description metadata? I think it only looks at the long_description metadata; as far as I know README is just another file in the archive. If

[Distutils] Re: proposing Python package index upload API spec (potential PEP)

I like this practice of writing specifications to better document interfaces that already exist. However, in this case I wonder if it would be better to spend the time defining a new, simpler API instead? I think we're currently in a position where most tools could use a new upload API

[Distutils] Re: org-mode README file formats

On Tue, May 8, 2018, at 5:44 PM, Brett Cannon wrote: > If it is an Emacs thing then I would vote "no" since that's very editor- > specific and I suspect trying to support every plaintext file format > is never-ending. Currently the metadata spec defines the permitted mimetypes. Maybe we should

[Distutils] Re: requirements.txt or not requirements.txt?

The recommendation is typically: setup.py for libraries, requirements.txt for applications. But you may also use requirements.txt for specific tasks associated with a library, like building the docs. Donald wrote a blog post which better explains what these two formats

[Distutils] Re: (Final) PyPI/Warehouse weekly report: legacy is shut down

Thanks Sumana & the team for all your work, and for these updates! On Wed, May 2, 2018, at 2:09 AM, Sumana Harihareswara wrote: > As I announced yesterday[1], here and on the pypi-announce[2] and > general Python announcement[3] lists, we have shut down > legacy.pypi.org, on schedule. (See the

[Distutils] Re: This list will soon be migrating to Mailman 3

On Mon, Apr 30, 2018, at 7:37 PM, Wes Turner wrote: > The signature footer from the message from you that ends with "I think > it's fixed now." appears to collapse in the Gmail interface,> but no longer > does with the new, helpful footer? I think the collapsing is a heuristic based on text seen

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

we should enforce that it's always there. Thomas On Sun, Apr 15, 2018, at 8:57 AM, Nick Coghlan wrote: > On 15 April 2018 at 17:31, Thomas Kluyver <tho...@kluyver.me.uk> wrote: > > The core metadata specification > > (https://packaging.python.org/specifications/core-meta

[Distutils] Package metadata: which fields are optional

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: - Download-URL is not marked as optional, but in practice it's obsolete (since PEP 470) and not very

Re: [Distutils] Pip 10.0 has been released

Thanks and congratulations to everyone who has worked on pip! On Sat, Apr 14, 2018, at 1:47 PM, Paul Moore wrote: > On behalf of the PyPA, I am pleased to announce that pip 10.0 has just > been released. This release has been the culmination of many months of > work by the community. > > To

Re: [Distutils] How to install examples files?

If I recall correctly, 'pip install --target' works by installing into a temporary directory, then copying only the library part to the target directory. So it will throw away any docs/examples/scripts that would be installed outside the importable package. On Tue, Apr 10, 2018, at 10:08 PM,

Re: [Distutils] Distributing packages to offline machines

On Thu, Apr 5, 2018, at 2:11 AM, Eric Gorr wrote: > (c) use https://warehouse.pypa.io/api-reference/json to look for > distributed wheels for the target OS and python version and > download them directly. (This may make for a nice flag to add to > pip somewhere...the ability to specify

Re: [Distutils] Github-Flavored Markdown is now supported on PyPI

A soon-to-be released version of flit will should make use of this automatically if your description file has a .md extension. On Wed, Apr 4, 2018, at 6:26 PM, Jon Wayne Parrott via Distutils-SIG wrote:> Hi distutils-sig, > If you haven't yet heard, as of April 1st PyPI (warehouse) supports >

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

On Fri, Mar 23, 2018, at 6:56 AM, alex.gronh...@nextday.fi wrote: > If someone wanted to make a malicious file, what's preventing them > from modifying the RECORD to match the modified file when there is no > cryptographic signing involved? Right: you need a way to verify RECORD on top of that.

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

On Thu, Mar 22, 2018, at 9:25 PM, alex.gronh...@nextday.fi wrote: > I've been wondering about something – zip files already contain CRC > based checksums for each the stored file. What benefit is there in > storing a RECORD file which basically duplicates this functionality? In terms of providing

Re: [Distutils] PyPI support for linux_ppc64le

On Mon, Mar 19, 2018, at 12:37 PM, Thomas Kluyver wrote: > If we're happy with that, I can also look at changing the glibc > version thing, but that will probably involve a bit more actual > thought. ;-) I've opened another PR for this: https://github.com/python/peps

Re: [Distutils] PyPI support for linux_ppc64le

On Wed, Mar 14, 2018, at 2:12 PM, Nick Coghlan wrote: > Mark was OK with changing PEP 571 over to manylinux2010, but there are > also some fixes needed for the current Platform Detection section, > which isn't spelling out the version of glibc used as the baseline > marker: >

Re: [Distutils] PyPI support for linux_ppc64le

On Mon, Mar 12, 2018, at 2:35 PM, Alex Grönholm wrote: > The manylinux1 platform only supports x86-64 and x86-32 (i686) > architectures. A quote from PEP 513:> Because CentOS 5 is only available for > x86_64 and i686 architectures, > these are the only architectures currently supported by the >

[Distutils] PEP 566 - Package metadata version 2.1

I'd like to once again prod this PEP towards completion: https://www.python.org/dev/peps/pep-0566/ The version numbering question has been decided in favour of calling it 2.1. The remaining question I'm aware of is whether to make the body text (in the email format of the metadata file)

Re: [Distutils] draft PEP: manylinux2

On Mon, Feb 5, 2018, at 2:38 PM, Ivan Pozdeev via Distutils-SIG wrote: > The point is, a year has negative informativity in this case. > > The very reasoning "compatible with most distributions released since > year " is flawed 'cuz it's vague and nonintuitive. Which is "most" > distributions?

Re: [Distutils] PEP 566 - metadata 1.3 changes

;> version.>> Shouldn't this be changed into 1.3 (along with ditching >> metadata.json)?>> >> >> Thomas Kluyver kirjoitti 12.01.2018 klo 17:26: >> > On Wed, Jan 10, 2018, at 11:42 PM, Nick Coghlan wrote: >> >> On 11 January 2018 at 00:54,

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

On Sat, Jan 13, 2018, at 6:39 PM, Matthias Bussonnier wrote: > Not opposing to open-id/Google-ID removal, but I would love to login-with- > google, though because I already have an account (and can't associate > my google account with the PyPI one) I'm not using login with google. > Also it did

Re: [Distutils] PEP 566 - metadata 1.3 changes

On Wed, Jan 10, 2018, at 11:42 PM, Nick Coghlan wrote: > On 11 January 2018 at 00:54, Daniel Holth wrote: > > AFAICT the only missing feature from old-Metadata-2.0 is "description as > > message body", which places readable description text after the key/value > > pairs. > > Do

[Distutils] PEP 566 - metadata 1.3 changes

I hope everyone has had a good break. :-) I'd like to see PEP 566 move forwards. From the last thread, I think people were mostly happy with it as stands, but there were some proposals to introduce further metadata changes. I'd suggest that we finalise the PEP as it currently stands, and save

Re: [Distutils] Immutability of Release Metadata in Warehouse

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 > still see Django 2.0.0 as

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

Dustin asked me to bring this issue to this thread: Metadata version 1.2 (PEP 345) says that version specifiers within a Requires-Dist field should go in parentheses: "zope.interface (>3.5.0)". The metadata spec on PyPUG repeats this. However, PEP 508 says that the parentheses are not needed,

[Distutils] Caching entry points - performance

To pick up the caching discussion again, I've started to experiment with a couple of different caching techniques. The headline results: a cold-start scan of entry points goes from about 4.5 seconds with no caching, to 0.45 seconds with caching. There's only a small difference (for me) between

Re: [Distutils] PEP 517 reference consumer

We have now done this, and you can see the new repo here: https://github.com/pypa/pep517 On Thu, Nov 16, 2017, at 01:31 PM, Paul Moore wrote: > I'm happy to (not sure what needs to be done, but I'm sure I can > muddle it through ;-)) > Paul > > On 16 November 2017 at 13:16, Thom

Re: [Distutils] PEP 517 reference consumer

On Thu, Nov 16, 2017, at 12:46 PM, Nick Coghlan wrote: > On 16 November 2017 at 21:22, Thomas Kluyver > <tho...@kluyver.me.uk> wrote:>> On Sun, Nov 12, 2017, at 10:51 PM, Nick > Coghlan wrote: >> > +1 from me, too. >> >&

Re: [Distutils] PEP 517 reference consumer

On Sun, Nov 12, 2017, at 10:51 PM, Nick Coghlan wrote: > +1 from me, too. Whose further agreement should we get for this? And - if there is agreement - how do we do the transfer? If someone briefly gives me permission to create repos in the PyPA org, I can use Github's transfer feature.

Re: [Distutils] PEP 517 reference consumer

On Sun, Nov 12, 2017, at 07:21 PM, Paul Moore wrote: > Is it (in your opinion) something that pip might be able to use? The > biggest potential hurdle, I would imagine, is that if pep517.envbuild > uses pip to install dependencies, and pip uses pep517.envbuild, > there's a risk of a recursive loop

[Distutils] PEP 517 reference consumer

I have found a bit more time to work on my PEP 517 consumer API: https://github.com/takluyver/pep517 It provides two main interfaces: - 'pep517.wrappers' is a lower-level interface to call the backend hooks in a subprocess. - 'pep517.envbuild' is a higher-level interface which creates a

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

On Tue, Oct 31, 2017, at 12:49 PM, Jeremy Stanley wrote: > Do the two share enough common code for successful uploading to a > devpi instance to be indicative of whether PyPI will accept or > reject on the grounds of, e.g., invalid trove classifiers (this one > in particular has been the most

Re: [Distutils] [proposal] shared distribution installations

On Mon, Oct 30, 2017, at 07:16 PM, RonnyPfannschmidt wrote: > in order to elevate those issues i would like to propose a new > installation layout, > where instead of storing each distribution in every python all > distributions would share a storage, and each individual environment > would only

Re: [Distutils] Entry points: specifying and caching

On Thu, Oct 26, 2017, at 03:57 PM, Daniel Holth wrote: > Would something as simple as a file per sys.path with the 'last > modified by installer' date be helpful? You could check those to > determine whether your cache was out of date. I wonder if we could use the directory mtime for this? It's

Re: [Distutils] Entry points: specifying and caching

On Sat, Oct 21, 2017, at 07:59 AM, 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 package > - hooks only

Re: [Distutils] Entry points: specifying and caching

On Fri, Oct 20, 2017, at 07:31 PM, Marius Gedminas wrote: > Please do not forget about gui_scripts entry points! I haven't forgotten about them in the draft spec: https://github.com/pypa/python-packaging-user-guide/pull/390/files#diff-089b079de062f6fdb759bb719b79e6c8R121

Re: [Distutils] Entry points: specifying and caching

On Fri, Oct 20, 2017, at 07:24 PM, Doug Hellmann wrote: > I have been trying to find time to do something like that within > stevedore for a while to solve some client-side startup performance > issues with the OpenStack client. I would be happy to help add it > to entrypoints instead and use it

Re: [Distutils] Entry points: specifying and caching

On Fri, Oct 20, 2017, at 01:58 PM, Wes Turner wrote: > What were the issues with setuptools entry points here (in 2014, when > you two were opposed to adding them to sendibly list ipython > extensions)? I'm impressed by your memory! The main issue then was that it implied that extension authors

Re: [Distutils] Entry points: specifying and caching

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 around how bad they > are, have refused to implement them because of previous pain felt by > them, are looking for ways

Re: [Distutils] Entry points: specifying and caching

On Fri, Oct 20, 2017, at 01:18 PM, Donald Stufft wrote: > I guess we shouldn’t have done PEP 517 or PEP 518 because, by your > logic here, since it won’t be supported by existing tooling, there > won’t be any incentive for people to use it ever. I see this as having a similar purpose to those

Re: [Distutils] Entry points: specifying and caching

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. Where packaging tools need to know about it, they already have to. Where they don't, writing a standard doesn't imply that

Re: [Distutils] Entry points: specifying and caching

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 not be created? Your time is enormously valuable, so why would you drop everything to write a PEP which implies changes

Re: [Distutils] Entry points: specifying and caching

I would also be happy to add a section to the document describing the specific use of entry points for defining scripts to install. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Entry points: specifying and caching

On Fri, Oct 20, 2017, at 05:42 AM, Nick Coghlan wrote: > I'm wondering if rather than jumping straight to a PEP, it may make > sense to instead initially pursue this idea as a *non-*standard, > implementation dependent thing specific to the "entrypoints" project. > There are a *lot* of challenges

Re: [Distutils] Entry points: specifying and caching

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 an INI file that > contains a section named “console_scripts” and define what is valid > inside of the console_scripts

Re: [Distutils] Entry points: specifying and caching

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, but setuptools > contains one of those too. Since setuptools was in large part a > packaging library, it will of

Re: [Distutils] Entry points: specifying and caching

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> wrote:>> >> I don't think this needs to be controversial. They are a de-facto >> packaging standard, whether or not that's t

Re: [Distutils] Entry points: specifying and caching

On Thu, Oct 19, 2017, at 07:09 PM, Donald Stufft wrote: > So heres a different idea that is a bit more ambitious but that I think > is a better overall idea. Let entrypoints be a setuptools thing, and lets > define some key lifecycle hooks during the installation of a package and > some mechanism

Re: [Distutils] Entry points: specifying and caching

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 *probably* be a a PEP (since > without (2), its just another file in the .dist-info directory and that > doesn’t actually

Re: [Distutils] Entry points: specifying and caching

On Wed, Oct 18, 2017, at 05:59 PM, Paul Moore wrote: > > I've always used the setuptools documentation as a reference. Are you > > suggesting moving that information to a different location to > > allow/encourage other tools to implement it as a standard? > > I've never used entry points myself

  1   2   3   >