[Distutils] Re: Shutting down distutils-sig, for real

What a wonderful new year's gift  On Thu, Dec 30, 2021, 11:05 AM Jeremy Stanley wrote: > On 2021-12-30 09:55:34 -0500 (-0500), Andrew M. Kuchling wrote: > [...] > > let's shut the list down for 2021! > [...] > > No objection from me at this point. While I find Discourse to > perform

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

You would have to have a high tolerance for learning SCons. I'm aware that this is not for everyone. Then you could write a SConstruct with dependent tasks in a normal build system way. e.g. target = env.Command("a task", ...) platlib = env.Whl("platlib", target, root=".") whl =

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

enscons is an alternative to distutils. -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org https://mail.python.org/mailman3/lists/distutils-sig.python.org/ Message archived at

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

I've been working on ensconced which lets you use a SConstruct to build. It is easier than customizing distutils. https://github.com/dholth/pysdl2-cffi/blob/master/SConstruct is the most code-generation-y project. Its build might be a little out of date and it has an independent setup.py building

[Distutils] Re: Shipping a Python C extension + a library it uses as source

If you're adventurous we could try to get it built and packaged with SCons. This extension generates code and then complies a cffi module: https://bitbucket.org/dholth/pysdl2-cffi/raw/a31bf1d1100bc4573ccadcd574f8fdc5cc841e1c/SConstruct On Tue, Jun 11, 2019, 16:13 Spencer Baugh wrote: > > Hi

[Distutils] Re: enscons 0.7.0 released with PEP517 support

Try python -m enscons.setup2toml and then run scons in your favorite python package. On Tue, May 21, 2019, 10:14 Nick Coghlan wrote: > On Sun, 12 May 2019 at 09:19, Daniel Holth wrote: > > > > And now for something completely different > > > > I've implemented P

[Distutils] enscons 0.7.0 released with PEP517 support

these pep517 powered builds "pluggable". Daniel Holth -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org https://mail.python.org/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.o

[Distutils] Re: Docker builds, ~/.pip/cache, and O(1) or O(n) bandwidth

Also you must set an environment variable for docker build to be able to use --mount On Tue, May 7, 2019, 12:28 Daniel Holth wrote: > That one is multistage, great feature, but I think cache mounts would work > fine with any number of stages. The mount option is a pretty new feature. >

[Distutils] Re: Docker builds, ~/.pip/cache, and O(1) or O(n) bandwidth

That one is multistage, great feature, but I think cache mounts would work fine with any number of stages. The mount option is a pretty new feature. On Tue, May 7, 2019, 12:24 Wes Turner wrote: > > > On Tuesday, May 7, 2019, Daniel Holth wrote: > >> Have you tried using bu

[Distutils] Re: Docker builds, ~/.pip/cache, and O(1) or O(n) bandwidth

Have you tried using buildkit and the RUN --mount option? I've done extra stuff here (downloading rpms in a second image first) but I think you could just use the cache option. It would also be easy to use a second image and COPY in old docker.

[Distutils] Re: psycopg2/psycopg2-binary

I was frustrated with this very wheel. I had hoped I could provide a locally compiled version in my local wheeldir on pip's path to be automatically picked up, but pip prefers the manylinux tag (not compiled on my own machine) to the standard local Linux tag (compiled on my machine). On Sat, Apr

[Distutils] Re: PEP-582 concerns

I like the pep at first glance. I have long thought that virtualenv was a weird solution to an artificial problem notwithstanding that all programming problems are artificial. Virtualenv looks good only because a global interpreter centric environment is bad. A program centric alternative is

[Distutils] Re: Announcing Wheelodex

I like it On Thu, Oct 18, 2018, 13:06 Dustin Ingram wrote: > What a great tool! I can see myself using this to explain to folks why > the metadata for a given release is broken or incorrect. It would be > really nice (for me) to be able to link to specific lines in the > metadata file, but I

[Distutils] Re: setuptools configuration in pyproject.toml

Yes! bdist_wheel is supposed to be how you install packages built with setuptools on platforms without setuptools, to give you time to write its replacement. On Tue, Sep 25, 2018, 15:39 Thomas Kluyver wrote: > On Tue, Sep 25, 2018, at 9:13 AM, Paul Moore wrote: > > I personally don't see much

[Distutils] Re: setuptools configuration in pyproject.toml

You could probably implement this outside of setuptools as an extension. Clients would add a load-toml line to setup.py. Do build requirements work yet? One obstacle might be reconciling the all-strings nature of .cfg with typed toml. On Mon, Sep 24, 2018, 12:06 RonnyPfannschmidt <

[Distutils] Re: disable building wheel for a package

be installed according to wheel. It comes from a call to distutils. pip has its own implementation. On my machine data goes into $virtualenv in a virtualenv and into /usr on system python. On Fri, Sep 14, 2018 at 11:26 AM Paul Moore wrote: > On Fri, 14 Sep 2018 at 16:03, Daniel Holth wr

[Distutils] Re: disable building wheel for a package

4/9/2018, at 22:25, Daniel Holth wrote: > > No one wants wheel to be able to install things outside of the virtualenv. > What people have repeatedly asked for is the ability to install things > somewhere besides $VIRTUAL_ENV/lib/python#.#/site-packages/, places like > $VIRTUAL_ENV/

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

Package version resolution is a completely different and np-complete problem. https://en.wikipedia.org/wiki/Boolean_satisfiability_problem On Thu, Aug 30, 2018 at 2:51 PM Chris Jerdonek wrote: > Broad question: is there a sense in which the same “resolver” logic could > be used for both

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

As far as I know no one has released a compiler that turns f-strings into not-f-strings. If something like that existed, then you could have two wheels for the same software, one that had been passed through the compiler to remove f-strings and gain compatibility with older Python. If you were

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

It's not an intuitive system. We have wheel tags to choose the best alternative wheel or fall back to sdist. So py3-none-any is fine for f-strings if no other candidate wheel (a list of all available wheels for the same version number of a package) has been compiled to not require f-strings. The

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

That's right. No one writes 2to3 but for python 3.6 -> 3.7. The js people do. If we got into it we could have wheel tags for that sort of thing. In practice only a few classes of tags are used. On Mon, Aug 27, 2018, 22:06 Nathaniel Smith wrote: > I think the answer to all of these questions is

[Distutils] Re: Accessing extras during install command

It was never stored. It would probably not be hard to check whether a particular extras dependencies were installed by using pkg_resources? On Tue, Aug 21, 2018, 11:01 Joni Orponen wrote: > Hello, > > I'd like to run different external programs during the install command > which are provided by

[Distutils]Re: Introducing XAR - SquashFS based mountable executables - Calling OS/Distro Maintainers

This is very cool. I'm glad to see attention towards packaging useful applications and not just libraries for web development in a virtualenv, and the limitations of zip compression are felt by our Python applications comprised of many separately compressed files. Is bdist_xar calling out to pip

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

According to a link in this chain, virtualenv lately copies python3.dll (+ python3.7 e.g.) on Windows. So hopefully the extension links with that dll. On Tue, Jul 17, 2018, 15:51 Nathaniel Smith wrote: > The promise behind the limited ABI is exactly that if your extension works > on 3.x, it

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

So it appears the "supports abi3" check on Windows is simply python 3.5+? There is also the question of which visual studio CRT is in use, which could break compat apart from the Python ABI. This is the change to add abi3 to wheel including an extension using it. Must pass a define, which should

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

The feature was a building block that was intended to be used in much the same way that SHA package hashes are used, providing similar security to the ssh-style TOFU model, but less security than other imaginable public key systems. The idea was that it could provide more security in practice

Re: [Distutils] PEP 566 - Package metadata version 2.1

er outstanding issues, so this should > be ready for Daniel's review. > > Thanks, > D. > > On Thu, Feb 15, 2018 at 2:09 PM, Trishank Kuppusamy > <trishank.kuppus...@datadoghq.com> wrote: > > On Thu, Feb 15, 2018 at 2:19 PM, Daniel Holth <dho...@gmail.com> w

Re: [Distutils] PEP 566 - Package metadata version 2.1

Given a good copy of hashes, this would be > useful to survive a compromise of any package index. > > Does this make sense? Please let me know if you have questions, and thanks! > > On Thu, Feb 15, 2018 at 1:31 PM, Daniel Holth <dho...@gmail.com> wrote: > >> I ag

Re: [Distutils] PEP 566 - Package metadata version 2.1

I agree but have simply not had time. Edit it to add something like "Instead of a description header, the description may be provided in the message body, e.g. after a completely blank line to end the headers, followed by the long description with no indentation or other special formatting

Re: [Distutils] PEP 566 - metadata 1.3 changes

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

Re: [Distutils] PEP 566 - metadata 1.3 changes

5 On Tue, Jan 16, 2018 at 12:08 PM Alex Grönholm wrote: > Whichever we choose, the metadata version should match the PEP version, > which it currently does not. > > Nathaniel Smith kirjoitti 16.01.2018 klo 18:58: > > On Jan 12, 2018 8:00 AM, "Alex Grönholm"

Re: [Distutils] PEP 566 - metadata 1.3 changes

> Thomas > > On Fri, Jan 12, 2018, at 4:02 PM, Daniel Holth wrote: > > Yes, after the PEP is prep'd. > > On Fri, Jan 12, 2018 at 11:00 AM Alex Grönholm <alex.gronh...@nextday.fi> > wrote: > > On the same note, wheel currently writes "2.0" as its metadata v

Re: [Distutils] PEP 566 - metadata 1.3 changes

; > 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, Daniel Holth <dho...@gmail.com> wrote: > >>> AFAICT the only missing feature from old-Metadata-2.0 is "description &

Re: [Distutils] PEP 566 - metadata 1.3 changes

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. On Wed, Jan 10, 2018 at 8:45 AM Thomas Kluyver wrote: > I hope everyone has had a good break. :-) > > I'd like to see

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

I don't know why the parentheses were included in the older pep. They are widely deployed. We probably can get rid of them or make them optional in a practical parser. On Sat, Dec 9, 2017, 02:03 Nick Coghlan wrote: > On 9 December 2017 at 02:42, Thomas Kluyver

Re: [Distutils] Caching entry points - performance

Neat On Thu, Nov 30, 2017 at 1:25 PM Thomas Kluyver wrote: > 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

Re: [Distutils] Entry points: specifying and caching

I agree. The "malware" problem is really a "how do I understand which hooks run in each environment" problem. The hooks could slow down or confuse, frustrate people in ways that were unrelated to any malicious intent. The caching could just be a more efficient, lossless representation of the

Re: [Distutils] Entry points: specifying and caching

I like the idea of lifecycle hooks but I worry about the malware problem; would there need to be a blacklist / whitelist / disable system? (ignore-scripts=true is now a recommended part of anyone's npm configuration) That is why we have avoided any kind of (package specific) hooks to wheel.

Re: [Distutils] Entry points: specifying and caching

I prefer a single more generic mechanism that packaging happens to use instead of making special mechanisms for scripts or other callables that packaging might some day be interested in. One API, I can type pkg_resources.iter_entry_points('console_scripts') to enumerate the scripts and perhaps

Re: [Distutils] Entry points: specifying and caching

ote: > On 19 October 2017 at 04:18, Alex Grönholm <alex.gronh...@nextday.fi> > wrote: > >> Daniel Holth kirjoitti 18.10.2017 klo 21:06: >> >> >> http://setuptools.readthedocs.io/en/latest/formats.html?highlight=entry_points.txt#entry-points-txt-entry-point-pl

Re: [Distutils] Entry points: specifying and caching

On Wed, Oct 18, 2017 at 2:57 PM Paul Moore wrote: > On 18 October 2017 at 19:42, Thomas Kluyver wrote: > > On Wed, Oct 18, 2017, at 05:59 PM, Paul Moore wrote: > >> > I've always used the setuptools documentation as a reference. Are you > >> >

Re: [Distutils] Entry points: specifying and caching

On Wed, Oct 18, 2017 at 2:18 PM Alex Grönholm <alex.gronh...@nextday.fi> wrote: > Daniel Holth kirjoitti 18.10.2017 klo 21:06: > > > http://setuptools.readthedocs.io/en/latest/formats.html?highlight=entry_points.txt#entry-points-txt-entry-point-plugin-m

Re: [Distutils] Entry points: specifying and caching

http://setuptools.readthedocs.io/en/latest/formats.html?highlight=entry_points.txt#entry-points-txt-entry-point-plugin-metadata http://setuptools.readthedocs.io/en/latest/pkg_resources.html?highlight=pkg_resources#creating-and-parsing It is not very complicated. It looks like the characters are

Re: [Distutils] Extracting distutils into setuptools

Enscons uses parts of distutils to get compiler flags and so on but does not use Extension() to do the actual compiling. There might be a cleaner way to do it that I was not able to find. There could be a cleaner separation between parts of distutils related to how Python itself was compiled and

Re: [Distutils] New wheel release (v0.30.0)

Thanks. This release also drops support for Python 2.6. It seems hardly anyone noticed. On Mon, Sep 11, 2017, 01:24 Nick Coghlan wrote: > On 11 September 2017 at 08:21, Alex Grönholm > wrote: > > I have now made my first wheel release as the new

Re: [Distutils] Migrating interoperability specs to packaging.python.org

inclusion of a metadata file which conforms to an > unaccepted PEP as potentially dangerous. > > Perhaps I should disable it in the next release? > > Daniel Holth kirjoitti 04.09.2017 klo 17:03: > > Some people enjoy using metadata.json which tracked pep 426 but I have > been meaning

Re: [Distutils] Migrating interoperability specs to packaging.python.org

Some people enjoy using metadata.json which tracked pep 426 but I have been meaning to take it out, and perhaps keep the key/value to json converter as a command. On Mon, Sep 4, 2017, 09:33 Nick Coghlan wrote: > Some time ago, I started the process [1] of adjusting how >

Re: [Distutils] why do we still put version numbers into dist-info folders

A long time ago pkg_resources was able to sometimes get the version number only from the .egg-info folder name, and skip opening the metadata at all when that data was not needed. We might always do listdir() for path in sys.path and parse every METADATA on the first pkg_resources import. On Fri,

Re: [Distutils] PEP 517 again

I don't think this is a big deal. Compatibility is a guess, wheel tags do not and are not intended to guarantee compatibility especially when the wheel was built locally for caching purposes and not intentionally published. Anything can happen during a build. PEP 517 won't change this. So right

Re: [Distutils] PEP 517 again

Don't be afraid of extras. They have not been PEP'd but are required for a useful Python packaging system. install_requires is just a shorthand for extras with the "" empty string as their name. Too bad we couldn't agree on ; vs : as the delimiter though. On Thu, Aug 31, 2017 at 2:04 PM Nathaniel

Re: [Distutils] PEP 517 again

On Thu, Aug 31, 2017 at 12:58 PM Chris Barker wrote: > On Thu, Aug 31, 2017 at 8:57 AM, Paul Moore wrote: > >> > As to using pip to build wheels -- there is good reason to do that >> > now, but in s post PEP 517 world, one would call the build system

Re: [Distutils] PEP 517 again

I'm not against renaming a wheel to adjust the tags, but it is a strange caching strategy. wheel is due for a 'retag' feature that does a more rigorous job of changing tags. The build system should name its wheels correctly. Normally the pyNN tag would be used for a pure distribution and the cpNN

Re: [Distutils] PEP 517 again

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 going to make a big difference. On Mon, Aug 28, 2017 at 3:59 PM Thomas Kluyver wrote: > On Mon, Aug 28, 2017, at 08:50 PM,

Re: [Distutils] PEP 517 again

On Mon, Aug 28, 2017 at 3:48 PM xoviat wrote: > > But I'm suspicious of the rationale that *there will be fewer frontends so > they should have more responsibility*. > > To be fair, pip is currently struggling to keep up with project > requirements as it is, which has caused

Re: [Distutils] PBR/distutils2 with pep517 Support Was: Conditionless setup.py

Imo PBR is entirely a setuptools creature, without special concerns to operate in pep517 land. If I were them I'd rewrite it to not require setup.py and call that pbr2. On Mon, Aug 28, 2017, 12:44 Chris Barker wrote: > I've thought for ages that we could transition to a

Re: [Distutils] PEP 517 again

Return none makes sense, but I don't think the outcome of that or the "configurable src path" decisions will affect the success of the proposal. On Sun, Aug 27, 2017, 05:59 Paul Moore wrote: > On 26 August 2017 at 23:13, Nathaniel Smith wrote: > > This

Re: [Distutils] PEP 517 again

I'm bored with that On Sat, Aug 26, 2017, 11:59 xoviat wrote: > Is everyone on board with that? > > On Aug 26, 2017 4:29 AM, "Paul Moore" wrote: > >> On 26 August 2017 at 03:17, Guido van Rossum wrote: >> > In pretty much any other

Re: [Distutils] Conditionless setup.py

It's important to realize that build is a Turing-complete activity. We write programs to build programs. Where setup.py gets in trouble is by making both the metadata and the build script the same thing, making it harder to reason about that metadata. That is why we are working towards being able

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

It would be simpler if the only requirement was to produce a correct wheel. On Thu, Aug 24, 2017, 20:07 Greg Ewing wrote: > Paul Moore wrote: > > 4. The point of all this is that the definition of build_directory > > says "If build_directory is None, the backend may

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

> > : > >> >> On 24 August 2017 at 15:13, Thomas Kluyver <tho...@kluyver.me.uk> wrote: >> >>> On Thu, Aug 24, 2017, at 06:20 PM, Daniel Holth wrote: >>> >>> On Thu, Aug 24, 2017 at 12:34 PM Thomas Kluyver <tho...@kluyver.me.uk> >&g

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

On Thu, Aug 24, 2017 at 12:34 PM Thomas Kluyver <tho...@kluyver.me.uk> wrote: > On Thu, Aug 24, 2017, at 05:26 PM, Daniel Holth wrote: > > by including the build_dir parameter, a nearly universal build system > concept, pip gets an elegant way to ask for either a clea

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

build_dir: bdist_wheel sometimes has a problem with unclean builds. admittedly this could be fixed. pip copies entire source tree, including unclean build/ directory, to tmpdir bdist_wheel runs in tmpdir, including copied leftover build/ data in wheel by including the build_dir parameter, a

Re: [Distutils] PEP 517: Bootstrapping setuptools

Isn't this a special case of needing . on sys.path when building a package? Then the same version of setuptools that is being packaged builds itself. I've experimented with a different kind of bootstrapping where pip installs setuptools on demand when the first setuptools requiring package is

Re: [Distutils] PEP 517: Build frontend responsibilities

It's probably a tiny wrapper running the hook in its own subprocess. Probably few modules loaded. On Sat, Aug 19, 2017, 14:31 xoviat wrote: > Ah the joy of Python 2.7; it seems I've forgotten its perils: unloading is > not possible which means that we would need to come up

Re: [Distutils] PEP 517: Build frontend responsibilities

Apart from the issues, can we get some prototype implementations? On Fri, Aug 18, 2017, 13:24 xoviat wrote: > Thomas: > > > What are the specific issues that need to be worked out? > > > Regards, > > > xoviat > > 2017-08-18 3:09 GMT-05:00 Thomas Kluyver :

Re: [Distutils] status check on PEP 517

Works for me El mar., 1 de ago. de 2017 11:32, Thomas Kluyver escribió: > Are we content to say that sys.path includes the source directory where > the hook is run? Shall I prepare a PR against the PEP for that? > > On Sun, Jul 30, 2017, at 02:12 PM, Nick Coghlan wrote: >

Re: [Distutils] status check on PEP 517

onh...@nextday.fi> wrote: > Daniel Holth kirjoitti 30.07.2017 klo 00:48: > > I think the proposal is that flit depends on click depends on flit and > neither one has a wheel and must be built from sdists. Then you have a > circular build problem. So don't do that. I put this

Re: [Distutils] status check on PEP 517

Pip has to vendor its dependencies primarily because it can't pip install them. Not the same problem as build systems. On Sat, Jul 29, 2017, 18:00 Alex Grönholm <alex.gronh...@nextday.fi> wrote: > Daniel Holth kirjoitti 30.07.2017 klo 00:58: > > Yes vendoring would be a soluti

Re: [Distutils] status check on PEP 517

What you would do is put your project in src/ and choose a build system that allows the same, if you happen to be developing such a conflicting project. On Sat, Jul 29, 2017 at 1:29 PM Paul Moore wrote: > On 29 July 2017 at 17:46, Nathaniel Smith wrote: > >

Re: [Distutils] status check on PEP 517

On Fri, Jul 28, 2017 at 7:12 PM Nathaniel Smith wrote: > On Fri, Jul 28, 2017 at 1:58 PM, Thomas Kluyver > wrote: > > I think this was actually a question that someone (Nathaniel?) brought > up: > > is the project source directory on sys.path when the

Re: [Distutils] status check on PEP 517

Yes, the cwd strongly should be on sys.path, so many possibilities, and we are used to that behavior in setup.py. On Fri, Jul 28, 2017 at 4:59 PM Thomas Kluyver <tho...@kluyver.me.uk> wrote: > On Fri, Jul 28, 2017, at 09:37 PM, Daniel Holth wrote: > > See how trivial it

Re: [Distutils] status check on PEP 517

See how trivial it would be to put the delegated sdist generator into the build-backend within the confines of the current PEP? The build-backend could point to a .py in the current directory that implements itself with different tools, or a delegating build backend could parse a separate

Re: [Distutils] status check on PEP 517

04:16 PM, Daniel Holth wrote: > > It looks like we've run out of things to say about PEP 517, except, how > soon can we get it into pip? > > > I admire your optimism! ;-) > > While I partly hope that I get a unanimous disagreement, as it would be > simpler, I have a nagging

Re: [Distutils] status check on PEP 517

It looks like we've run out of things to say about PEP 517, except, how soon can we get it into pip? These function signatures will serve us well, significantly lowering the barrier to entry for new pip-compatible build systems. On Thu, Jul 20, 2017 at 3:36 PM Brett Cannon

Re: [Distutils] Maintenance of the "wheel" package

Fine by me, probably inevitable, obviously I'm not a fan of git. Please take care of the useful pending pull requests on bitbucket first. On Tue, Jul 25, 2017 at 9:05 AM Alex Grönholm wrote: > Looking at the commit history, the maintenance of "wheel" has more or less >

Re: [Distutils] requirements for variable python

Do you just need a conditional dependency? extras_require={ ':python_version=="2.7"': ['functools32'], On Wed, Jul 19, 2017 at 11:20 AM Robin Becker wrote: > Is there a way to build a universal wheel which needs an additional module > when > python 2.7 is

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

iel Smith <n...@pobox.com> wrote: > On Mon, Jul 17, 2017 at 6:36 AM, Daniel Holth <dho...@gmail.com> wrote: > > Here's my own summary. > > > > pip can do build_sdist -> unpack sdist -> build wheel if it wants to, > > serving as some kind of linter if y

Re: [Distutils] Notes on pip's requirements for PEP 517

A minor detail for pip strategy option #2 is that sdists do not have to have PKG-INFO. On Mon, Jul 17, 2017 at 9:02 AM Nathaniel Smith wrote: > Hi all, > > I happened to talk to Donald on IRC last night, and said I'd write up > some notes on that discussion. (He's also seen

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

Here's my own summary. pip can do build_sdist -> unpack sdist -> build wheel if it wants to, serving as some kind of linter if you happen to run 'pip install .' during development. build_directory provides a way to ask for a clean build, the lack of which causes problems in bdist_wheel

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

I agree that sdist consistency is not enforceable. Very little is. What if we deleted every unenforceable part of the PEP? No explanations of what backends should do. Every parameter is a hint. If you put the output file where requested then you are a good back end. Would that work better?

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

I proposed the build directory parameter because the copytree hook made no sense to me. It is not a perfect substitute but perhaps a configurable build directory is nice on its own without having to satisfy all older arguments in favor of copytree. I think true in-place builds are the oddball (for

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

The PEP process is awful. Sorry. Thank you for helping to make this happen. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

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

On Tue, Jul 11, 2017 at 9:58 AM Thomas Kluyver wrote: > To summarise the current state of this discussion as I understand it, > the hooks we are currently thinking of defining are: > > def get_build_wheel_requires(config_settings) > def

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

On Mon, Jul 10, 2017, 10:58 C Anthony Risinger wrote: > On Jul 10, 2017 8:59 AM, "Nick Coghlan" wrote: > > On 10 July 2017 at 22:08, Jeremy Stanley wrote: > > On 2017-07-10 20:33:16 +1000 (+1000), Nick Coghlan wrote: > > [...] >

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

A huge benefit to using non distutils build systems is making it easy to generate files at any step. I just don't think it's worth it to force a particular build directory at the generate sdist phase. Foolish consistentcy. On Mon, Jul 10, 2017, 10:20 Paul Moore wrote: > On

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

Sdists contain generated PKG-INFO and .egg-info. I'd prefer to let the build backend manage any sdist build directory. It doesn't provide the same benefit to pip as the configurable wheel build directory. On Mon, Jul 10, 2017, 08:09 Jeremy Stanley wrote: > On 2017-07-10

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

On Mon, Jul 10, 2017, 04:54 Steve Dower wrote: > One nice thing about providing a “put your work in this directory” setting > for all tasks is that only the front end has to know how and where to > create it, and how and when to clean it up later. Users may want to >

Re: [Distutils] Distutils question

Jeremy Kloth <jeremy.kl...@gmail.com> wrote: > On Sat, Jul 8, 2017 at 9:09 PM, Daniel Holth <dho...@gmail.com> wrote: > >> Unrelated to pep 517, remind me whether when invoking setup.py build -b >> dir bdist, if the -b argument passed to the build command is supposed to &

[Distutils] Distutils question

wrote: > On Fri, Jul 7, 2017 at 9:45 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > > On 7 July 2017 at 23:23, Daniel Holth <dho...@gmail.com> wrote: > >> FYI distutils supports out of tree builds too. It is the -b argument to > >> 'setup.py build'. > > &g

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

On Fri, Jul 7, 2017 at 9:23 AM Daniel Holth <dho...@gmail.com> wrote: > FYI distutils supports out of tree builds too. It is the -b argument to > 'setup.py build'. > And it works in bdist_wheel by adding half a dozen lines. It copies the -b argument to the 'build' subcommand, so

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

FYI distutils supports out of tree builds too. It is the -b argument to 'setup.py build'. On Fri, Jul 7, 2017 at 7:08 AM Paul Moore wrote: > Also, please note that the proposal doesn't *prohibit* in-place > builds, quite the opposite, it allows backends to decide when asked

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

It might be more natural to pass a build directory for intermediate build artefacts along with the wheel output directory to the build wheel hook. This would remove pip from an awkward position of managing a copy step in the middle of a build and would be more like out of tree builds in other

[Distutils] how sdist generation works in enscons

Here's how sdist generation works in enscons. enscons, a build tool that exists to prototype new Python packaging features, is just a set of tools for SCons that makes it easier to generate wheels and sdists. If targets with certain names exist (sdist, bdist_wheel) then the provide setup.py shim

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

-1 on _for_ ; why should a common prefix plus extra typing be any clearer than common suffix? Or rearrange the words without _for_. For the --config options, there's a double dash on the key and the value, I found that confusing. I suppose the theory, not thoroughly explained, is that the value

Re: [Distutils] Finishing up PEP 517

; want, and then youd call > > scons build_wheel > which is aliased Alias('build_wheel','variant_dir for building wheel path') > > Maybe bring this up on scons users mailing list and we'll see if it can be > resolved? > > On Wed, Jun 28, 2017 at 6:42 PM, Daniel Holth <dho..

Re: [Distutils] Finishing up PEP 517

The other thing I noticed is that build-system requires has no hyphen but build-backend does. On Wed, Jun 28, 2017, 22:28 Daniel Holth <dho...@gmail.com> wrote: > That would fit with setup.py, which also likes to sys.exit() after one > command. > > On Wed, Jun 28, 2017, 22:25 N

Re: [Distutils] Finishing up PEP 517

That would fit with setup.py, which also likes to sys.exit() after one command. On Wed, Jun 28, 2017, 22:25 Nick Coghlan <ncogh...@gmail.com> wrote: > On 29 June 2017 at 11:42, Daniel Holth <dho...@gmail.com> wrote: > > I was able to implement PEP 517 build_wheel and bu

Re: [Distutils] Finishing up PEP 517

) by default. "Alakazam!" On Wed, Jun 28, 2017 at 3:52 PM Thomas Kluyver <tho...@kluyver.me.uk> wrote: > On Wed, Jun 28, 2017, at 06:07 PM, Daniel Holth wrote: > > Is there a prototype implementation of pep 517 yet? > > > - Flit has a PR with a prototype backend im

Re: [Distutils] Finishing up PEP 517

Is there a prototype implementation of pep 517 yet? On Wed, Jun 28, 2017, 06:58 Robert Collins wrote: > > > Re: returning magic strings to indicate exceptions. Please no. Just no. > Have any pep build host add a small library to Python path with any symbols > we want

Re: [Distutils] Finishing up PEP 517

My impressions on reading what is hopefully the current version of the PEP Are there different paths to get to sdist/wheel for example tree -> prepare sdist/wheel files -> build sdist and tree -> build sdist, tree -> build wheel depending on what [pip] decides to do? Should the frontend do both

  1   2   3   4   5   6   7   8   9   >