[Distutils] Entry points: specifying and caching

We're increasingly using entry points in Jupyter to help integrate third-party components. This brings up a couple of things that I'd like to do: 1. Specification As far as I know, there's no document describing the details of entry points; it's a de-facto standard established by setuptools. It

Re: [Distutils] Reproducible builds (Sdist)

On Fri, Sep 29, 2017, at 07:16 PM, Matthias Bussonnier wrote: > Second; is there a convention to store the SDE value ? I don't seem to > be able to find one. It is nice to have reproducible build; but if > it's a pain for reproducers to find the SDE value that highly decrease > the value of SDE

[Distutils] PEP 517 - is it ready?

Discussion on PEP 517 seems to have settled down, and I believe that Nick said he was about ready to accept it. Is everyone involved satisfied with the current state? Or is there anything else you think should be considered before accepting it? https://www.python.org/dev/peps/pep-0517/

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

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 characters. - Frontends that want the wheel to end up elsewhere can ask for it in a tmp

Re: [Distutils] PEP 517 again

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 going to make a big difference. Will that work now? Are we all so tired of this

Re: [Distutils] PEP 517 again

On Mon, Aug 28, 2017, at 08:50 PM, Paul Moore wrote: > My main motivation for wavering is that I thought agreeing to trust > the backend would simplify many of the decisions, and it's immensely > frustrating to me that we're still debating the same question in the > "return None" thread. The

Re: [Distutils] PEP 517 again

On Mon, Aug 28, 2017, at 08:20 PM, Paul Moore wrote: > Maybe we go fully to Nick's proposal that we don't mandate any sort of > consistency constraints in the PEP. That would mean pip *has* to go > sdist->wheel (because pip does need consistent behaviour), and > xoviat's setuptools backend can

Re: [Distutils] PEP 517 again

If pip does uses build_wheel directly, as Paul now prefers, I think we can leave the NotImplemented/Error/None question for a later date. We only want some way to signal "I can't do that" because a frontend might try sdist->wheel with a fallback to making a wheel directly. If no frontend is

Re: [Distutils] PEP 517 - a plan of action

Thanks Paul for providing us with a way to move forwards. I'm in favour of what you propose. On Sun, Aug 27, 2017, at 11:37 AM, Paul Moore wrote: > 2. Thomas to complete and publish his library of helper functions for > PEP 517 consumers (optional - but I think he said he had such a thing > in

Re: [Distutils] PEP 517 again

On Fri, Aug 25, 2017, at 10: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. I'm not sure

Re: [Distutils] PEP 517 again

On Fri, Aug 25, 2017, at 10:02 PM, xoviat wrote: > While we're waiting for others to respond, what are we going to do > with respect to the sys.path issue? I don't think there has been > discussion on that yet. I'm more or less persuaded by Nathaniel's argument that the source directory shouldn't

Re: [Distutils] PEP 517 again

On Fri, Aug 25, 2017, at 09:50 PM, xoviat wrote: > Genius! 1% inspiration, 99% frustration :-P ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] PEP 517 again

On Fri, Aug 25, 2017, at 09:41 PM, xoviat wrote: > There's no need to return an instance of the exception class. As long > as it is defined in the same name space as the hooks the front end > will be able to access it. No, I meant NotImplementedError. As in: if i_cant_do_it: return

Re: [Distutils] PEP 517 again

What if hooks returned instances of the exception class? That way it doesn't bubble up from internal code, it can carry a message, and we can all agree that it's a semantically terrible idea that doesn't fit with any conventions. Even I'm not sure if this is a serious suggestion. ;-) On Fri, Aug

Re: [Distutils] PEP 517 again

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 can include a message - The return value can't 'bubble up' from the internals of a hook

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

On Fri, Aug 25, 2017, at 11:56 AM, Thomas Kluyver wrote: > Great, I think we're on the same page. I'm going to make a PR against > the PEP while I still remember what page it is. ;-) https://github.com/python/peps/pull/364 ___ Distutils-SIG ma

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

On Fri, Aug 25, 2017, at 11:45 AM, Paul Moore wrote: > If it can't build a sdist then there's no opportunity for frontends to > fall back to sdist->wheel anyway, so that's not an issue[1]. > > It's only if sdist->wheel and direct wheel are both possible that > frontends have a choice, and I feel

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

Thanks Paul, On Fri, Aug 25, 2017, at 10:45 AM, Paul Moore wrote: > I'd *also* expect that the wheel built (and hence what gets installed) > would be the same as what you'd get if the user added write > permissions and then ran the command. That's part of what I mean by > direct wheel and

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

On Fri, Aug 25, 2017, at 08:47 AM, Paul Moore wrote: > I've never cared about whether the backend modifies the source tree, > only that the direct-wheel / sdist->wheel equivalence holds. If a user types 'pip install .' in a directory where they don't have write permissions, what should happen?

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

On Thu, Aug 24, 2017, at 07:30 PM, Leonardo Rochael Almeida wrote: > It looks like a lot of trouble for a feature that is designed to > solve a problem for a very thin intersection of the Venn diagram of > people who:> > a. wants to quickly iterate while hacking a package > > b. doesn't want

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

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> wrote:>> Is there a reason to ask for an 'unclean' > build, though? There may be >> a performance optimisation from reusing cached data,&

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

On Thu, Aug 24, 2017, at 03:29 PM, xoviat wrote: > I understand that, but what I disagree with is modifying build_wheel > to make up for a lack of consensus on editable installs. The reasoning for the build_directory parameter was not based around editable installs. This is the confusion I was

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

On Thu, Aug 24, 2017, at 03:05 PM, xoviat wrote: > During development, you want to use an editable install, which does > modify the source tree. I think it was before you joined the discussion, but editable installs came up before and have deliberately been left out of PEP 517 because of the

Re: [Distutils] PEP 517 again

On Thu, Aug 24, 2017, at 02:21 PM, xoviat wrote: > I mean is this golang or Python? In Python, you raise > notimplementederror. But there's a NotImplemented singleton in Python as well. The argument for using a return value is that the hook code has to deliberately return that, whereas a

[Distutils] PEP 517 again

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. > - needs some sort of NotImplemented(Error) handling specified We've gone round

Re: [Distutils] PEP 517: Bootstrapping setuptools

On Wed, Aug 23, 2017, at 05:37 AM, Nick Coghlan wrote: > On 23 August 2017 at 05:24, xoviat wrote: > > The question that I have is: how does flit address this issue? Does flit > > require external dependencies to bootstrap itself? > > It does, but those dependencies currently

Re: [Distutils] PEP 517: Build frontend responsibilities

> 2017-08-18 14:08 GMT-05:00 xoviat <xov...@gmail.com>: >> I have attempted to implement prototype machinery here[1] and >> here[2], but it's been widely ignored IHMO because as Thomas said, >> the spec keeps changing.>> >> 2017-08-18 12:37 GMT-05:00 Thomas Kl

Re: [Distutils] PEP 517: Build frontend responsibilities

t; >> Regards, >> >> >> xoviat >> >> 2017-08-18 3:09 GMT-05:00 Thomas Kluyver <tho...@kluyver.me.uk>: >>> On Fri, Aug 18, 2017, at 07:09 AM, Nick Coghlan wrote: >>> > The other aspect I'm not clear on is whether or not both PEP >

Re: [Distutils] PEP 517: Build frontend responsibilities

I'll let Nathaniel relay them. On Fri, Aug 18, 2017, at 06:23 PM, 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 <tho...@kluyver.me.uk

Re: [Distutils] PEP 517: Build frontend responsibilities

On Fri, Aug 18, 2017, at 07:09 AM, Nick Coghlan wrote: > The other aspect I'm not clear on is whether or not both PEP authors > are otherwise happy for the current version to be *considered* for > acceptance Nathaniel has mentioned to me a list of issues he sees that we still need to work

Re: [Distutils] status check on PEP 517

On Tue, Aug 15, 2017, at 04:42 PM, Brett Cannon wrote: > I'm also willing to bet that Thomas is busy prepping for JupyterCon. Sadly I won't be at JupyterCon. I'm avoiding all travel to the US in the current political situation. ___ Distutils-SIG

Re: [Distutils] status check on PEP 517

On Wed, Aug 2, 2017, at 01:05 PM, Nick Coghlan wrote: > I wouldn't say that, as the two most clearly side effect free ways of > putting the source directory on sys.path are: > > 1. make it the current working directory for a "python -m" or "python > -c" invocation, so that the current directory

Re: [Distutils] status check on PEP 517

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: > On 30 July 2017 at 02:46, Nathaniel Smith wrote: > > Or am I worrying about a non-issue

Re: [Distutils] status check on PEP 517

On Sat, Jul 29, 2017, at 09:47 AM, Paul Moore wrote: > +1 from me on just adding the project root to sys.path. Ditto. I don't expect most projects to use it, but it seems like a handy bit of flexibility to have available. The potential clutter is a bit ugly, but I don't think it's worth the

Re: [Distutils] status check on PEP 517

On Fri, Jul 28, 2017, at 09:37 PM, Daniel Holth wrote: > See how trivial it would be to put the delegated sdist generator into the > build-backend within the confines of the current PEP? I agree that delegation within the backend is a reasonable answer to this. > The build-backend could point to

Re: [Distutils] status check on PEP 517

On Fri, Jul 28, 2017, at 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 concern

Re: [Distutils] status check on PEP 517

I'm also not going to have much time to keep discussing this over the next few days. On Thu, Jul 20, 2017, at 11:22 AM, Paul Moore wrote: > 2) I'd much rather if we're going for a "stop and take stock" style of > reset, that we base that off what's currently in the official version > of the PEP.

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

On Mon, Jul 17, 2017, at 02:56 PM, Nick Coghlan wrote: > If Thomas is OK with it, I'd be fine with using "raise > NotImplementedError" for that purpose. I will implement this if it's what we decide, but I agree with Nathaniel that a sentinel value is probably more robust, because return values

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

On Mon, Jul 17, 2017, at 01:07 PM, Paul Moore wrote: > If we have a consensus here that "build a sdist and build a wheel from > it" is an acceptable/viable main route for pip to generate wheels > (with "just ask the backend" as fallback) then I'm OK with not > bothering with an "ask the backend to

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

On Sat, Jul 15, 2017, at 08:33 PM, Donald Stufft wrote: > I wonder if maybe it would be more useful to simply recommend that instead of > shelling out to random vcs binaries that these projects depend on (or bundle) > libraries to directly interact with a repository. For instance, if your >

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

On Sat, Jul 15, 2017, at 03:28 PM, Nick Coghlan wrote: > For flit, there are two main cases of interest: > > - publisher development environments > - building from release tarballs rather than VCS clones > > In the first case, the typical scenario will have both VCS metadata > *and* VCS tools

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

On Sat, Jul 15, 2017, at 12:54 PM, Paul Moore wrote: > Given that this is the case we're talking > about, my experience is that working directories contain all sorts of > clutter - small test files I knocked up, experimental changes I > discarded, etc. That may simply reflect the way I work, but

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

On Fri, Jul 14, 2017, at 11:59 AM, Nathaniel Smith wrote: > What are the advantages of this design, as compared to the > fallback of doing unconditional copytree (like pip does now and may > well continue doing for years to come regardless of what we say here), I don't think pip currently does

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

On Fri, Jul 14, 2017, at 11:18 AM, Nathaniel Smith wrote: > OTOH this whole 11th hour discussion of forcing every build system to > have in-tree and out-of-tree build support is solving some other > problem. It is not my intention to force build systems to support either of these. - Where build

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

On Tue, Jul 11, 2017, at 04:48 PM, Daniel Holth wrote: > Pro_duced. > > Mandatory backend hooks: > > - build_sdist(sdist_directory, config_settings={}) > - build_wheel(wheel_directory, config_settings={}, build_directory=None, > metadata_directory=None)> > Optional backend hooks: > > -

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

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 prepare_wheel_metadata(metadata_directory, config_settings) def build_wheel(wheel_directory, config_settings,

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

On Mon, Jul 10, 2017, at 04:13 PM, Nick Coghlan wrote: > My apologies folks, this is an entirely irrelevant tangent brought on > by my attempting to explain my own preference that source archives > (including sdists) actually *be* source archives, containing solely > the original software is

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

On Mon, Jul 10, 2017, at 07:01 AM, Nick Coghlan wrote: > So I think we have pretty solid evidence that the reason the > procedural "build directory preparation" hook wasn't sitting well with > people was because that isn't the way build systems typically model > the concept, while a "build

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

On Thu, Jul 6, 2017, at 11:51 PM, Paul Moore wrote: > On reflection, I'm less concerned about this than I was. If you wanted > to propose a stripped down version of PEP 517 which assumed it was the > backend's responsibility to ensure reproducible isolated builds, I'd > be willing to listen. But

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

On Thu, Jul 6, 2017, at 10:40 PM, Daniel Holth wrote: > 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

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

On Thu, Jul 6, 2017, at 07:19 PM, Paul Moore wrote: > That's a good point - and provides a good contrast to my perspective > as a pip developer that *pip* gets issues raised that aren't really > pip's problem. I think it's in everyone's best interests to ensure > that the user's experience is as

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

On Thu, Jul 6, 2017, at 06:19 PM, Donald Stufft wrote: > I *think* if we had some way to signal expected failure vs unexpected failure > this would be reasonable to me. I wouldn’t just want it to flat out be any > failure, but if we used Nathaniels NotImplemented idea or something similar > to

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

Thanks Nick for the detailed reply. I have read it carefully, and you've probably convinced me to get back on board. Some more responses inline: On Thu, Jul 6, 2017, at 03:38 PM, Nick Coghlan wrote: > While I can completely understand how the current debate over whether > or not the

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

On Thu, Jul 6, 2017, at 11:55 AM, Paul Moore wrote: > On 6 July 2017 at 11:26, Ralf Gommers wrote: > > I hope you'll reconsider that deprecation - flit is one of only two (AFAIK) > > active attempts at making a saner build tool (enscons being the other one), > > and does

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

Thank-you all for the discussion and the attempts to accommodate flit, but I'll bow out now. It's become clear that the way flit approaches packaging is fundamentally incompatible with the priorities other people have for the ecosystem. Namely, I see sdists as archival artifacts to be made

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

On Wed, Jul 5, 2017, at 05:08 PM, Paul Moore wrote: > is that flit doesn't handle scenarios like "I unpacked a sdist" or "I > downloaded the project archive from github and unpacked that" well. Flit handles these fine for everything *apart* from making an sdist. It can make a wheel, install the

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

On Tue, Jul 4, 2017, at 06:24 PM, Donald Stufft wrote: > It occurs to me that your case here is actually a reason *not* to > implement this hook. The goal of the hook is that the wheel built from > the tree created by copying this file is the same as the wheel built > from a sdist created from

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

On Tue, Jul 4, 2017, at 09:45 AM, Nick Coghlan wrote: > +1, but we should explicitly note in the rationale section of the PEP > that it's to cover both of the following cases: > > * build from an already unpacked and potentially edited sdist" > * cleanly support explicitly out-of-tree builds even

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

On Tue, Jul 4, 2017, at 01:06 AM, Donald Stufft wrote: > 2) We have a VCS directory or “original development source” or >whatever you want to call the thing you have before a sdist that >typically gets into a sdist.> - Works on both proposals for setuptools > and flit (since both can

Re: [Distutils] Finishing up PEP 517

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 implementation, though it's not up to date with all the changes the PEP has undergone. I'll update it when we've agreed on a spec - it's

Re: [Distutils] Provide separate development and documentation URLs in PyPI metadata?

On Tue, Jun 27, 2017, at 04:58 PM, Barry Warsaw wrote: > On Jun 25, 2017, at 11:33 AM, Nick Coghlan wrote: > >I'd favour "Participate" over any variant of "Contribute", as without > >context, "Contribute" makes me think of financial support in the > >crowdfunding/tip jar sense. > > "Participate"

Re: [Distutils] Finishing up PEP 517

On Sun, Jun 25, 2017, at 08:41 AM, Nick Coghlan wrote: > Aside from not producing an archive, the bit that makes > `prepare_wheel_build_files` notably different from `build_sdist` is > that it relies on `get_build_wheel_requires` *not* on > `get_build_sdist_requires`: >

Re: [Distutils] Provide separate development and documentation URLs in PyPI metadata?

On Sat, Jun 24, 2017, at 06:34 PM, Brett Cannon wrote: > Anyway, just an idea I had based on my flit experience yesterday plus > a tweet sent to me. (And if PyPI already supports this somehow then > Thomas should brace for the feature request from me .) This prompted me to go and look at the

Re: [Distutils] Finishing up PEP 517

Nick has merged that PR, and the updated PEP is visible here: https://www.python.org/dev/peps/pep-0517/ Hopefully we're nearing a consensus on this now. If you're interested, please do have a read through the latest version. Thomas On Sat, Jun 24, 2017, at 02:44 PM, Thomas Kluyver wrote: >

Re: [Distutils] Finishing up PEP 517

I have prepared a PR against the PEP adding get_build_sdist_requires , and renaming a couple of the other hooks for clarity (get_build_wheel_requires, prepare_build_wheel_files): https://github.com/python/peps/pull/297 ___ Distutils-SIG maillist -

Re: [Distutils] ANNOUNCE: Sunsetting of uploading to the legacy PyPI/TestPyPI

For reference, I switched the default upload server for flit in version 0.11. On Sat, Jun 24, 2017, at 08:45 AM, Nick Coghlan wrote: > On 24 June 2017 at 15:24, Nick Coghlan wrote: > > https://packaging.python.org/guides/tool-recommendations/ is missing a > > section on

Re: [Distutils] Finishing up PEP 517

On Fri, Jun 16, 2017, at 10:48 PM, Nathaniel Smith wrote: > The messy complications come from > prepare_wheel_metadata and get_prepare_wheel_input_files, which isn't > surprising, since those are the two hooks where we're squinting into > our crystal ball to try and guess what will be useful for

Re: [Distutils] PEP 517: Python 3 finder?

On Fri, Jun 16, 2017, at 10:01 PM, Nathaniel Smith wrote: > On Jun 16, 2017 12:13 PM, "Daniel Holth" wrote: >> Build systems should be able to run under a different version of >> Python than the one that is running 'pip install'. Does PEP 517 have >> anything to say about that?>

Re: [Distutils] Finishing up PEP 517

On Fri, Jun 16, 2017, at 08:41 AM, Nick Coghlan wrote: > > I think we should rename get_build_requires to > > get_build_wheel_requires, and add a get_build_sdist_requires. And the > > rule would be: > > > > get_build_sdist_requires: can assume build-system.requires are available > >

Re: [Distutils] PEP 517: Open questions around artifact export directories

On Thu, Jun 15, 2017, at 03:10 PM, C Anthony Risinger wrote: > I'm not trying to open a bikeshedding opportunity here -- and I tried > to ignore it, honest! -- but why are tarballs preferable to zipfiles > for sdists?> > ... > > Just seems a little odd/arbitrary to me that wheel is zip, python >

[Distutils] Finishing up PEP 517

Yes, it's PEP 517 again! Here's the current text: https://www.python.org/dev/peps/pep-0517/ We currently say: > All other hooks [except get_build_requires] are executed in an environment > which contains both the bootstrap requirements specified in the > pyproject.toml hook and those

Re: [Distutils] PEP 517: Open questions around artifact export directories

I have updated the PR as requested: 1. Specify the PAX format, and note that it is not yet the default for the tarfile module in Python. 2. Updated the self-contained backend example with Nick's suggestions. Thomas On Wed, Jun 14, 2017, at 08:53 AM, Paul Moore wrote: > On 14 June 2017 at 02:53,

Re: [Distutils] PEP 517: Open questions around artifact export directories

On Tue, Jun 13, 2017, at 02:27 AM, Nick Coghlan wrote: > Despite being the one to originally propose standardisation on passing > directory paths around, I'm starting to lean back towards this > approach. > > My rationale for this doesn't really have a lot to do with topics > we've discussed so

Re: [Distutils] PEP 517: Open questions around artifact export directories

On Mon, Jun 12, 2017, at 10:23 PM, Donald Stufft wrote: > because it allows the front ends more flexibility in how they use > the wheels I don't get this? Why is it more flexible? > and allows us to avoid doing work, making the process involved faster > for everyone. This is true so long as

Re: [Distutils] PEP 517: Open questions around artifact export directories

On Mon, Jun 12, 2017, at 10:09 PM, Donald Stufft wrote: > It’s pretty hard to screw up zipping up a directory. If you want reproducible builds, it's very easy to screw up, and your response doesn't inspire confidence that frontends will do it carefully. But I see flit mainly as something you use

Re: [Distutils] PEP 517: Open questions around artifact export directories

On Mon, Jun 12, 2017, at 09:45 PM, Daniel Holth wrote: > I think all my wheel generators except bdist_wheel build the zipfile > directly. There is a certain appeal to using the zipped .whl file as the canonical format for all tools that produce or consume wheels, rather than defining a closely

Re: [Distutils] PEP 517: Open questions around artifact export directories

On Sat, Jun 10, 2017, at 06:14 PM, Nick Coghlan wrote: > Thomas - I agree with Donald's reasoning here, so would you mind > updating the PEP accordingly? I've done so here: https://github.com/python/peps/pull/290 There are still a couple of questions on which I wasn't quite sure what the

Re: [Distutils] PEP 517: Open questions around artifact export directories

On Sat, Jun 10, 2017, at 04:32 AM, Nick Coghlan wrote: > 1. Move all artifact naming responsibilities to the frontend. All > backend hooks would just write files in the defined format into the > directory supplied by the frontend (and those directories would have > no defined naming scheme -

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On Sat, Jun 3, 2017, at 10:55 AM, Paul Moore wrote: > This is getting very off-topic, but what if I wanted to patch the > source and then build a sdist to put into my local PyPI index? I > presume the answer is that I either have to checkout the original > sources from VCS or I have to build only

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On Sat, Jun 3, 2017, at 03:14 AM, Nathaniel Smith wrote: > If the pip devs don't trust build systems in general, but (as > suggested by copy_files discussion) are ok with trusting them if they > promise to be super trustworthy, alternate proposal: > - add a 'in_place_build_safe = True' hook, which

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On Fri, Jun 2, 2017, at 06:14 PM, Donald Stufft wrote: > The steps here would basically be (for building from something that > isn’t already a .tar.gz or a .whl): That sounds OK to me. I think the only remaining point of contention is whether the build_sdist hook should make an archive or an

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On Fri, Jun 2, 2017, at 05:26 PM, Nick Coghlan wrote: > Could you provide a little more detail as to what you would do > differently in exporting the contents of an sdist that wouldn't apply > to export a build tree? (aside from skipping emitting PKG-INFO) When creating an sdist, I query the VCS

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On Fri, Jun 2, 2017, at 03:41 PM, Nick Coghlan wrote: > Instead, the flow that I think makes sense is "VCS -> sdist tree [-> > sdist tree -> sdist tree -> ...] -> wheel", and the above model where > the export filtering is only used when PKG-INFO doesn't exist yet will > give us that. I still

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On Fri, Jun 2, 2017, at 03:12 PM, Paul Moore wrote: > I'm struggling to understand why building a sdist in flit should need > a VCS. It bothers me that I'm missing something important about how > backends will work, that explains why (for example) you can't create a > sdist from an export of a VCS

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

As was suggested at some point, I have added a build_sdist hook to my PR, with the following details: - A brief definition of the minimal requirements of an sdist. - I have limited the definition to gzipped tarballs. Zip files also work as sdists, but we're moving towards standardising on

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On Thu, Jun 1, 2017, at 10:49 PM, Paul Moore wrote: > pip also needs a way to deal with "pip install . In > this case, pip (under its current model) copies that directory to a > working area. In that area, it runs the build command to create a > wheel, and proceeds from there. In principle,

Re: [Distutils] Malicious packages on PyPI

On Thu, Jun 1, 2017, at 06:32 PM, Matt Joyce wrote: > It's basically a test dummy package that reports users who have ran > that package template. That's what I thought, but all the code to do the upload seems to have been removed before s/he built those packages. Now it's just a harmless warning,

Re: [Distutils] Malicious packages on PyPI

. On Thu, Jun 1, 2017, at 06:18 PM, Thomas Kluyver wrote: > Are we aware of this? > http://evilpackage.fatezero.org/ > > I recall there were a couple of these before which were taken down, but > someone appears to have made a cookiecutter template so you can very > easily claim names o

[Distutils] Malicious packages on PyPI

Are we aware of this? http://evilpackage.fatezero.org/ I recall there were a couple of these before which were taken down, but someone appears to have made a cookiecutter template so you can very easily claim names on PyPI, and anyone who installs that package will submit their information to

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On Wed, May 31, 2017, at 09:16 PM, Donald Stufft wrote: > How you build the release-quality sdist isn’t really of concern of PEP > 517 any more than building a release quality wheel is, it’s up to the > build tool to implement that as it makes sense for them. But if we have a hook for building

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On Wed, May 31, 2017, at 08:20 PM, Donald Stufft wrote: > I am struggling to figure out where there is opposition to simply > exposing something in a standard way, that you were already planning > on implementing anyways. I have issues with it because: 1. Building a *release-quality* sdist is a

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On Wed, May 31, 2017, at 07:40 PM, Donald Stufft wrote: > Taking pip completely off the table a second, let’s take a look at > tox. Tox’s default mode of operation is to produce a sdist. Now let’s > say I’m writing a project that I want to use PEP 517 and get rid of > setup.py, except now tox is

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

I've made an alternative PR against PEP 517 which defines a prepare_build_files hook, defined in terms of copying the files needed to build a package rather than making an sdist. https://github.com/python/peps/pull/277 ___ Distutils-SIG maillist -

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On Wed, May 31, 2017, at 06:03 PM, Donald Stufft wrote: > generating a sdist is an important thing to have be possible, and it > needs to be done in a way that it can be invoked generically. I agree that it needs to be possible to make an sdist, but can we leave the generic interface for it to be

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On Wed, May 31, 2017, at 04:31 PM, Donald Stufft wrote: > The hook is also so a tool like tox or TravisCI or twine can produce a > sdist that can be uploaded to PyPI or similar. This seems like a distinct operation from 'prepare the files needed to build a wheel', although they are related. For

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On Wed, May 31, 2017, at 03:00 PM, Thomas Kluyver wrote: > I would be fine with specifying a hook to copy only the files needed to > build the wheel, but if we do that, let's not call it 'sdist' or > anything that suggests that. Also, if this is all we're after, I'd like to push again f

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On Wed, May 31, 2017, at 02:57 PM, Paul Moore wrote: > My feeling is that in the current context we're talking about "minimal > set of files needed to build the wheel". That's not precisely a sdist > (because it ignores additional files that the user might want to > include like README, COPYRIGHT,

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On Wed, May 31, 2017, at 02:24 PM, Nick Coghlan wrote: > Cool, thanks for doing that - I'll let you thrash out the details with > Thomas as the PEP author, and then take a look once you're in > agreement on the amendments you want to make. I've had a quick look over the PR, and my main thought is

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

What about saying that the copying step, if necessary, is part of the build backend's responsibilities? I.e. pip doesn't copy the whole directory to a temporary build location, but the build backend may decide to do that at its discretion when it's asked to build a wheel. pip would continue to

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

I'm struggling to understand the objections here. As I understand the PEP, the input to building a wheel is a source tree. That may come from an unpacked sdist or a VCS checkout; hopefully those contain basically the same files, give or take some unimportant generated files in an sdist. This seems

<    1   2   3   >