Re: [Distutils] flit adapter for the current sdist format

Thanks Daniel, that's interesting to see. For flit, I don't see a major benefit in generating sdists - for pure Python packages, universal wheels are simpler and install quicker. I'd really like to improve installing directly from a source tree, such as a VCS checkout. To do that, any adapter

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On 12 October 2015 at 05:37, Robert Collins wrote: > And a bugfix :) - I didn't link to the docs for the build system > interface we have today - > https://pip.pypa.io/en/latest/reference/pip_install/#build-system-interface > I'm happy to see that the command line

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On 12 October 2015 at 11:01, Robert Collins wrote: > Python packaging config in $root/pypa.yaml > > Defined keys: > > ... > build-tool: > # basic command that will spit a hunk of json back to the caller > defining the > # commands to use with the build tool. >

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On 2 October 2015 at 12:58, Donald Stufft wrote: > The first thing that immediately stood out to me, is that it's recommending > that downstream redistributors like Debian, Fedora, etc utilize Wheels > instead > of the sdist to build their packages from. However, that is not

[Distutils] Add data-requires-python attribute to download links in simple repository API

In a discussion about how to allow pip to select a package version compatible with the target Python version, Donald suggested adding a data-requires-python attribute to links in the simple repository API, which pip uses to find candidate downloads. ... This would expose the Requires-Python

Re: [Distutils] Outdated packages on pypi

On Fri, Jul 15, 2016, at 01:25 AM, Donald Stufft wrote: > Off the top of my head I can only really think of PIL, and *maybe* > suds. Unless there’s a lot of these maybe all we really need is a > policy for when administrators can/will edit the page to direct people > towards a different project or

Re: [Distutils] package made up of only .so's?

Hi Chris, On 7 July 2016 at 11:49, Chris Withers wrote: > flit does look nice and clean, but appears to only support one > module/package? > Thomas, that ever likely to change? That's by design, I'm afraid. I like one top-level module to correspond to one installable

Re: [Distutils] Proposal: "Install and save"

On Sat, Jul 23, 2016, at 02:32 PM, Alex Grönholm wrote: > I'm -1 on this because requirements.txt is not really the standard way > to list dependencies. > In the Python world, setup.py is the equivalent of Node's package.json. > But as it is > Python code, it cannot so easily be programmatically

Re: [Distutils] Deprecating little used file types/extensions on PyPI?

On Mon, Aug 15, 2016, at 08:09 PM, Donald Stufft wrote: > Finally, bdist_egg is quite possibly the trickiest one to justify. A fair > number of people still upload eggs, even though we have the wheel format. > However, I think that we should (and generally do) consider eggs to be > deprecated and

[Distutils] Indexing modules in Python distributions

For a variety of reasons, I would like to build an index of what modules/packages are contained in which distributions ('packages') on PyPI. For instance: - Identifying requirements by static analysis of code: 'import zmq' -> requires pyzmq - Finding corresponding packages from different

Re: [Distutils] Indexing modules in Python distributions

Thanks Steve, Chris, On Tue, Feb 7, 2017, at 04:49 PM, Chris Wilcox wrote: > I may be able to help jump-start this a bit and provide a platform for > this to run on. I deployed a small service that scans PyPI to figure > out statistics on Python 2 vs Python 3 support using PyPI Classifiers. >

Re: [Distutils] recommended strategy for missing development tools

On Wed, Jan 25, 2017, at 10:23 AM, Robin Becker wrote: > The setup.py in question complains if the > extension files cannot be found, but does not error. There was a change in pip at some point which means that it only shows the output from setup.py if running it fails (i.e. it has a non-zero

Re: [Distutils] Virtalenv and setuptools [was: latest setuptools appears to require six in a breaking way]

On Wed, Jan 25, 2017, at 08:02 PM, Donald Stufft wrote: > Since we have a PR up for PEP 518 already, Here's the link if anyone wants to take a look: https://github.com/pypa/pip/pull/4144 ___ Distutils-SIG maillist - Distutils-SIG@python.org

Re: [Distutils] Virtalenv and setuptools [was: latest setuptools appears to require six in a breaking way]

On Wed, Jan 25, 2017, at 09:02 PM, Paul Moore wrote: > Thanks. I've been seeing the PR comments in passing, but haven't > really looked in detail. Is there anything I can do to help this > along? I believe it's working, but it's the first significant change I've made in pip, so any review is

Re: [Distutils] distlib and wheel metadata

On Thu, Feb 23, 2017, at 02:28 PM, Paul Moore wrote: > I'd also drop "used to develop and deploy Python libraries, > applications, and scripts" - why does what it's used for affect its > category? Things for working on & with Python code often have installation requirements a bit different from

Re: [Distutils] Indexing modules in Python distributions

On Wed, Feb 8, 2017, at 11:06 PM, Wes Turner wrote: > So, IIUC, > you're looking to emit > ((URL, release, platform), namespaces_odict) > for each new and all existing packages; > by uncompressing every package and running every setup.py (hopefully > in a container)? Something like that,

Re: [Distutils] Indexing modules in Python distributions

s anyone there have some time to put in to move this forwards? Thomas On Thu, Feb 9, 2017, at 10:18 PM, Jeremy Stanley wrote: > On 2017-02-08 18:14:38 +0000 (+0000), Thomas Kluyver wrote: > [...] > > What I'm proposing differs in that it would need to download files from > > PyPI - basic

Re: [Distutils] distlib and wheel metadata

On Wed, Feb 15, 2017, at 03:40 PM, Daniel Holth wrote: > It would make sense to go ahead and delete the obsolete fields, I'm > sure they were overlooked because they are not common in the wild. > > From PEP 345: > * Deprecated fields: >* Requires (in favor of Requires-Dist) >*

Re: [Distutils] Why I like eggs (or similar mechanisms) and my thoughts on future of buildout

On Sun, Aug 21, 2016, at 05:19 PM, Jim Fulton wrote: > I'm open to shelling out, but pessimistic that it will turn out well. > I started with that approach initially with easy_install and it fell > apart quickly. But when we get into it... who knows? I think shelling out is a reasonable approach

Re: [Distutils] Proposed new Distutils API for compiler flag detection (Issue26689)

On Mon, Aug 22, 2016, at 07:15 AM, Sylvain Corlay wrote: > I find this worrying that the main arguments to not include a patch > would be that > > - this part of the standard library is not very maintained (things >don't get merged) > - earlier versions of won't have it Would it make sense

Re: [Distutils] PEP 527 - Removing Un(der)used file types/extensions on PyPI

On Thu, Aug 25, 2016, at 12:30 PM, Nick Coghlan wrote: > My one remaining question would be whether or not we have any projects > that are in the habit of uploading both .zip and .tar.gz for the same > release - if there are, the restriction to only one sdist per release IPython's release script

Re: [Distutils] setup_requires: the obvious option(?)

On Tue, Aug 30, 2016, at 05:51 PM, Antony Lee wrote: > I am not really a fan of PEP518 in general. Basically, the idea of > setup.py is that declarative languages are not sufficient to express a > build system (and AFAICT this is always going to be the case for > expressing, say, compiler flags

Re: [Distutils] Best way to handle packaging a project that only applies to certain versions of Python

There is also the 'python requires' metadata, which can now be provided via setuptools, but I think pip 8.2 needs to be released before that is respected. On Tue, Aug 30, 2016, at 01:08 AM, Daniel Holth wrote: > Let's say you have different code for python 3.3 and python 3.4+. Tag > one wheel

Re: [Distutils] Module Installation Issues

On Wed, Sep 14, 2016, at 04:31 PM, Paul Moore wrote: > Of course, it doesn't solve the problem of a user who doesn't know > what a "shell prompt" is... Especially since the interactive Python interpreter is also a shell prompt. The title of an IDLE window on my system is "Python 3.5.2 Shell" ;-).

Re: [Distutils] Module Installation Issues

On Tue, Sep 13, 2016, at 08:39 PM, Steve Dower wrote: > It would help if you could post the full error output (sanitizing > paths if needed). But you may just need to upgrade pip (python -m > install -U pip). I think Ryan may have typed that command at a Python prompt rather than a system command

Re: [Distutils] Module Installation Issues

On Thu, Sep 15, 2016, at 01:53 PM, Wes Turner wrote: > Shell commands can/could/should be clearly indicated with a '$' > prefix: > > $ python -m pip install numpy That's a common convention, but: - It comes from POSIX platforms where the default prompt ends in $. The default prompt in

Re: [Distutils] Deprecating little used file types/extensions on PyPI?

On Mon, Aug 15, 2016, at 08:40 PM, Donald Stufft wrote: > Or were you wondering for the last 30 days like I did for downloads? If > so then: > > * sdist: 15601 (66%) > * bdist_wheel: 6398 (27%) > * bdist_egg: 1076 (4.5%) > * bdist_dumb: 195 (0.8%) > * bdist_wininst: 167 (0.7%) > * bdist_rpm: 38

Re: [Distutils] PEP 527 - Removing Un(der)used file types/extensions on PyPI

On Thu, Aug 25, 2016, at 05:29 PM, Nick Coghlan wrote: > Could you give a bit more detail on how you came to be publishing > both? The main thing we're trying to avoid is missing a practical use > case for the status quo where folks can upload both - if it's just an > artifact of Windows and *nix

Re: [Distutils] PEP 517: Build system API

On Wed, Nov 23, 2016, at 07:22 PM, Donald Stufft wrote: > I think at a minimum we should get PEP 518 support into pip first. I > don't think layering more things on top of a PEP that isn't yet > implemented is a good approach to this. I went to make a start on this, but I got stuck on whether

[Distutils] PEP 517: Build system API

I'd like to push PEP 517 forwards again. This PEP specifies a general build system interface so that a source tree can specify a tool (such as flit), and pip can ask that tool to generate a wheel. This would allow us to install from an sdist or a VCS checkout without running a setup.py file.

Re: [Distutils] PEP 517: Build system API

On Thu, Nov 24, 2016, at 08:07 PM, Paul Moore wrote: > Just curious - how does flit handle Windows for this? Symlinks aren't > really an option there (you need elevation to create a symlink). > Paul It largely doesn't at present; it started out as a personal tool for me, and I mostly use Linux. I

Re: [Distutils] PEP 517: Build system API

On Thu, Nov 24, 2016, at 07:50 PM, Thomas Kluyver wrote: > I made a PR to flit to handle this case better in uninstallation. I meant a PR to *pip*. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listi

Re: [Distutils] PEP 517: Build system API

I've made PRs against PEP 517 for: Underscore to dash in build-backend: https://github.com/python/peps/pull/139 1a: Add a user parameter to the install_editable hook https://github.com/python/peps/pull/140 OR: 1c: Get rid of the install_editable hook https://github.com/python/peps/pull/141

Re: [Distutils] Interrogate distribution for an entry point command path

On Sat, Oct 15, 2016, at 06:57 PM, Ben Finney wrote: > I'm modifying an existing application that invokes the program as a > subprocess, so I'm wanting to find that program as an external command. If the entry point looks like: foo=foomod:main Then you can invoke it in a subprocess by running:

Re: [Distutils] PEP 517: Build system API

On Thu, Nov 24, 2016, at 11:10 PM, Paul Moore wrote: > Honestly, I don't see what's so bad about pth files. They are a > standard supported Python approach. Maybe setuptools' use of them is > messy? I recall it was possible to end up with a lot of clutter, but > that was going back to the egg

Re: [Distutils] obtaining project name and packages

I have a tool that does this from a wheel: https://github.com/takluyver/wheeldex >From an sdist, I think you need to either build a wheel or install it before you can get this information reliably. Some of my installed packages have a 'top_level.txt' file in the .dist-info folder, containing a

Re: [Distutils] reproducible builds

Flit already supports $SOURCE_DATE_EPOCH for building wheels. I think the environment variable is a good idea: if it gets wide support, you will be able to set a single thing to affect lots of different build tools, rather than working out where you need to add command line arguments to half a

Re: [Distutils] reproducible builds

On Mon, Mar 20, 2017, at 01:02 PM, Robin Becker wrote: > Well now I am confused. The date / times mentioned in the debian patch > are those > we force into the documents produced by the reportlab package when it is > used. > > They would not normally be part of the package itself. Although the >

Re: [Distutils] Idea: Using Trove classifiers for platform compatibility warnings

On Sat, Apr 8, 2017, at 03:17 AM, Nick Coghlan wrote: > 2. At least one "Programming Language :: Python" tag is set, but the > tags don't include any that cover the *current* Python version We've just enabled setuptools, PyPI and pip to use the python-requires metadata field, so that (for

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 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] 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

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 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 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

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 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 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 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

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 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 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 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] 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 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] 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] 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] 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

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 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

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 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] 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] 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] 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

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

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] 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

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

> 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: 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

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] 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 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 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] 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

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] 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

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] 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] PEP 517 - specifying build system in pyproject.toml

On Sat, May 20, 2017, at 07:54 AM, Nick Coghlan wrote: > * on platforms with 8-bit standard streams (e.g. Linux, Mac OS X), > build systems SHOULD emit UTF-8 encoded output > * on platforms with 16-bit standard streams (e.g. Windows), build > systems SHOULD emit UTF-16-LE encoded output I'm quite

Re: [Distutils] PEP 517 - specifying build system in pyproject.toml

On Sat, May 20, 2017, at 05:36 PM, Steve Dower wrote: > I'll probably read the PEP closely and see that this is entirely > incorrect, but if it's right: > > * encoding for text between the build UI and build tool should just be > specified once for all platforms (i.e. use UTF-8). +1 > *

Re: [Distutils] Introducing PyPIContents

Hi Luis, Awesome, thanks for this :-). It was me posting before about indexing PyPI. I'm intrigued: how do you keep it up to date using Travis? When I looked into this, I was pretty sure you need to download every package to index it. Do you have some way to only download the new releases? Or is

Re: [Distutils] PEP 517 - specifying build system in pyproject.toml

On Tue, May 23, 2017, at 09:08 AM, Paul Moore wrote: > I strongly > prefer using the locale encoding as the assumed encoding for the > output stream rather than UTF-8. I may have missed it, but has anyone proposed what it should do if it wants to send characters which can't be encoded in the

Re: [Distutils] PEP 517 - specifying build system in pyproject.toml

On Tue, May 23, 2017, at 11:04 AM, Paul Moore wrote: > However, if we do this then we have a situation where existing build > tools (compilers, etc) that we have to support still use platform > dependent encodings. That's a reality that we can't wish away. And the > majority of real-life issues

Re: [Distutils] PEP 517 - specifying build system in pyproject.toml

On Tue, May 23, 2017, at 12:56 PM, Paul Moore wrote: > So based on your proposal, won't you introduce similar bugs by using > print() without sorting out encodings? Unless (see below) you assume > that the frontend sorts it out for you. If you strictly follow the locale encoding, you need to sort

Re: [Distutils] PEP 517 - specifying build system in pyproject.toml

On Tue, May 23, 2017, at 04:20 PM, Nick Coghlan wrote: > Up to this point, I've been in favour of both 1b and 2b, since they're Noted. > However, I also realised that there's a potential third way to handle > this problem: design a Python level API that allows front ends to use > more structured

Re: [Distutils] PEP 517 - specifying build system in pyproject.toml

On Wed, May 24, 2017, at 01:22 AM, Chris Jerdonek wrote: > 1) Would it make sense to provide a way for build tools to specify > what encoding they use (e.g. if not using the default), instead of > changing their encoding to conform to a standard? It seems like that > could be easier, although I

[Distutils] PEP 517 - specifying build system in pyproject.toml

Hi, I'd like to make another push for PEP 517, which would make it possible to build wheels from a source tree with other build tools, without needing setup.py. https://www.python.org/dev/peps/pep-0517/ Last time this was discussed we made a couple of minor changes to the PEP, but we didn't

Re: [Distutils] Introducing PyPIContents

On Sat, May 20, 2017, at 07:29 PM, Luis Alejandro Martínez Faneyth wrote:> It supports ['.whl', '.egg', '.zip', '.tgz', '.tar.gz', '.tar.bz2'] > formats, and it extracts the data using any available. Nice! If there are multiple of those formats present, does it get the data from just one? Or does

Re: [Distutils] PEP 517 - specifying build system in pyproject.toml

On Sat, May 20, 2017, at 07:36 PM, Steve Dower wrote: > Require that build tools either send UTF-8 to the UI component, or write > bytes to a file and call it a build output. I see no benefit in > requiring both the build tool and the UI tool to guess what the text > encoding is. I'm not

Re: [Distutils] PEP 517 - specifying build system in pyproject.toml

I have made a PR against the PEP with my best take on the encoding situation: https://github.com/python/peps/pull/264/files On Mon, May 22, 2017, at 11:19 AM, Paul Moore wrote: > On 22 May 2017 at 10:56, Thomas Kluyver <tho...@kluyver.me.uk> wrote: > > On Sat, May 20, 2017, at

Re: [Distutils] PEP 517 - specifying build system in pyproject.toml

On Mon, May 22, 2017, at 12:02 PM, Paul Moore wrote: > The only reservation I have is that the choice of UTF-8 means that on > Windows, build backends pretty much have to explicitly manage tool > output (as they are pretty much certain *not* to output in UTF-8). > Build backend writers that aren't

Re: [Distutils] PEP 517 - specifying build system in pyproject.toml

On Thu, May 25, 2017, at 03:38 PM, Nick Coghlan wrote: > Seeing it like this pushes me from "Eh, maybe?" to "No, definitely not" > [on the log directory] :) That's fine by me. It does feel like unwanted extra complexity for both backends and frontends. And backends dealing with output in an

Re: [Distutils] PEP 517 - specifying build system in pyproject.toml

On Thu, May 25, 2017, at 02:27 PM, Paul Moore wrote: > I'd be concerned here that we risk making the frontend UI a lot more > complex for little actual benefit. I'd rather we stick with the > current model, where a backend just has some output to pass through to > the frontend. Let's get a

Re: [Distutils] PEP 517 - specifying build system in pyproject.toml

On Fri, May 19, 2017, at 03:41 PM, Paul Moore wrote: > Can we specify what encoding the informational text must be written > in? Sure, that makes sense. What about: All hooks are run with working directory set to the root of the source tree, and MAY print arbitrary informational text on stdout

  1   2   3   >