<p dir="ltr"><br>
On Oct 11, 2015 11:07 PM, "Robert Collins" <<a href="mailto:robertc@robertcollins.net">robertc@robertcollins.net</a>> wrote:<br>
><br>
> EWOW, huge thread.<br>
><br>
> I've read nearly all of it but in order not to make it massively<br>
> worse, I'm going to reply to all the points I think need raising in<br>
> one mail :).<br>
><br>
> Top level thoughts here, more point fashion with only rough editing<br>
> below the fold.<br>
><br>
> I realise many things - like the issue between different wheels of the<br>
> same package consuming different numpy abis - have been touched on,<br>
> but AFAICT they are entirely orthogonal to the proposal, which was to<br>
> solve 'be able to use arbitrary build systems and still install with<br>
> pip'.<br>
><br>
> Of the actual problems with using arbitrary build systems, 99% of them<br>
> seem to boil down to 'setup-requires isn't introspectable by pip<br>
> (<a href="https://github.com/pypa/pip/issues/1820">https://github.com/pypa/pip/issues/1820</a> ). - If it was, then<br>
> alternative build systems could be depended on reasonably; and the<br>
> mooted thunk from setuptools CLI to arbitrary build system would be<br>
> viable.<br>
><br>
> It is, in principle a matter of one patch to teach pip *a* way to do<br>
> this (and then any and all build systems that want to can utilise it).<br>
> <a href="https://github.com/rbtcollins/pip/tree/declarative">https://github.com/rbtcollins/pip/tree/declarative</a> is a POC I did - my<br>
> next steps on that were to discuss the right ecosystem stuff for it -<br>
> e.g. should pip consume it via setuptools, or should pip support it as<br>
> *the way* and other systems including setuptools can choose to use it?</p>
<p dir="ltr">as a standard RDF graph representation,<br>
JSON-LD would be uniquely portable here.</p>
<p dir="ltr">"PEP 426: Define a JSON-LD context as part of the proposal"<br>
<a href="https://github.com/pypa/interoperability-peps/issues/31">https://github.com/pypa/interoperability-peps/issues/31</a></p>
<p dir="ltr">><br>
> A related but separate thing is being able to *exclusively* install<br>
> things without setuptools present - I've filed<br>
> <a href="https://github.com/pypa/pip/issues/3175">https://github.com/pypa/pip/issues/3175</a> about that, but I think its<br>
> -much- lower priority than reliably enabling third party build tools.</p>
<p dir="ltr">peep may not need setuptools?<br>
* SHA256<br>
* --no-deps<br>
* <a href="https://pypi.python.org/pypi/peep">https://pypi.python.org/pypi/peep</a><br>
* wheels<br><br></p>
<p dir="ltr">><br>
> -Rob<br>
><br>
> ----<br>
><br>
><br>
> "<br>
> solved many of the hard problems here -- e.g. it's no longer necessary<br>
> that a build system also know about every possible installation<br>
> configuration -- so pretty much all we really need from a build system<br>
> is that it have some way to spit out standard-compliant wheels.<br>
> "<br>
><br>
> Actually pip still punts a *lot* here - we have bypasses to let things<br>
> like C compiler flags be set during wheel build, and when thats done<br>
> we don't cache the wheels (or even try to build wheels).<br>
><br>
> "<br>
> While ``distutils`` / ``setuptools`` have taken us a long way, they<br>
> suffer from three serious problems: ...<br>
> (c) you are forced to use them anyway, because they provide the<br>
> standard interface for installing python packages expected by both<br>
> users and installation tools like ``pip``."<br>
><br>
> I don't understand the claim of (c) here - its entirely possible to<br>
> write a package that doesn't use setuptools and have it do the right<br>
> thing - pip uses a subprocess to drive package installation, and the<br>
> interface is documented. The interface might be fugly as, but it<br>
> exists and works. It is missing setup-requires handling, but so is<br>
> setup.py itself. The only thing we'd really need to do AFAICT is make<br>
> our setuptools monkeypatching thunk handle setuptools not being<br>
> installed (which would be a sensible thing to Just Do anyhow).<br>
><br>
> "<br>
> - query for build dependencies<br>
> - run a build, producing wheels as output<br>
> - set up the current source tree so that it can be placed on<br>
>   ``sys.path`` in "develop mode"<br>
> "<br>
><br>
> So we have that already. setup.py egg-info, setup.py bdist_wheel,<br>
> setup.py develop.<br>
><br>
> "A version 1-or-greater format source tree can be identified by the<br>
> presence of a file ``_pypackage/_pypackage.cfg``.<br>
> "<br>
><br>
> I really don't like this. Its going to be with us forever, and its<br>
> intrusive (its visible), and so far isn't shown to be fixing anything.<br>
><br>
><br>
> "to scatter files around willy-nilly never works, so we adopt the<br>
> convention that names starting with an underscore are reserved for<br>
> official use, and non-underscored names are available for<br>
> idiosyncratic use by individual projects."<br>
><br>
> I can see the motivation here, but is it really solving a problem we have?<br>
><br>
><br>
> On the specifics of the format: I don't want to kibbitz over strawman<br>
> aspects at this point.<br>
><br>
> Having the extension mechanism be both pip specific and in Python<br>
> means that we're going to face significant adoption issues: the former<br>
> because pip is not by any means the only thing around - and some<br>
> distros have until very recently been actively hostile to pip (which<br>
> in turn means we need to wait a decade or two for them to age-out and<br>
> stop being used). The latter because we'll face all the headaches of<br>
> running arbitrary untrusted code and dealing with two deps with<br>
> different versions of the same hook and so on: I think its an<br>
> intrinsically unsafe design.<br>
><br>
> @dstufft "problem with numpy.distutils, as I know you’re aware!). We<br>
> could do a minimal extension and add another defacto-ish standard of<br>
> allowing pip and setuptools to process additional setup_requires like<br>
> arguments from a setup.cfg to solve that problem though. The flip side<br>
> to this is that since it involves new capabilities in<br>
> pip/setuptools/any other installer is that it you’ll have several<br>
> years until you can depend on setup.cfg based setup_requires from<br>
> being able to be depended on.<br>
> "<br>
><br>
> Well. For *any* proposal that involves modifying pip, we have to<br>
> assume that all existing things keep working, and that anyone wanting<br>
> to utilise the new thing will have to either a) include a local<br>
> compatibility thunk, or b) error when being used from a too-old<br>
> toolchain. I don't think that should really be a factor in design<br>
> since its intrinsic to the quagmire.<br>
><br>
> "Longer term, I think the answer is sdist 2.0 which has proper<br>
> metadata inside of it (name, version, dependencies, etc) but which<br>
> also includes a hook like this PEP has to specify the build system<br>
> that should be used to build a wheel out of this source distribution."</p>
<p dir="ltr">a composed JSON-LD document indicating provenance (who, what, when) for each part of the build chain [VCS archive, egg-info, sdist, wheel, bdist]</p>
<p dir="ltr">pydist.jsonld?</p>
<p dir="ltr">><br>
> Any reason that can't just be setup.cfg ?<br>
><br>
> @Daniel "I thought Robert Collins had a working setup-requires<br>
> implementation already? I have a worse but backwards compatible one<br>
> too at <a href="https://bitbucket.org/dholth/setup-requires/src/tip/setup.py">https://bitbucket.org/dholth/setup-requires/src/tip/setup.py</a>" -<br>
> <a href="https://github.com/rbtcollins/pip/tree/declarative">https://github.com/rbtcollins/pip/tree/declarative</a> - I'll be updating<br>
> that probably early next year at this rate - after issue-988 anyhow.<br>
> The issue with your approach is that pip doesn't handle having<br>
> concurrent installs done well - and in fact it will end up locking its<br>
> environment somehow.<br>
><br>
> @Paul "<br>
> I can understand that a binary wheel may need a certain set of<br>
> libraries installed - but that's about the platform tags that are part<br>
> of the wheel definition, not about dependencies. Platform tags are an<br>
> ongoing discussion, and a good example of a partial solution that" -<br>
> thats where the draft PEP tennessee and I start is aimed - at making<br>
> those libraries be metadata, not platform tags.<br>
><br>
> @Chris "<br>
> A given package might depend on numpy, as you say, and it may work<br>
> with all numpy versions 1.6 to 1.9. Fine, so we specify that in<br>
> install_requires. And this shodl be the dependency in the sdist, too.<br>
> If the package is pur python, this is fine and done.<br>
><br>
> But if the package has some extensions code that used the numpy C API<br>
> ( a very common occurrence), then when it is built, it will only work<br>
> (reliably) with the version of numpy it was built with.<br>
><br>
> So the project itself, and the sdist depend on numpy >=1.6, but a<br>
> build binary wheel depends on numpy == 1.7 (for instance).<br>
><br>
> Which requires a binary (wheel) dependency that is somewhat different<br>
> than the source dependency.<br>
> " - so yes, that is where bdist_wheel should be creating different<br>
> metadata for that wheel. The issue that arises is that we need unique<br>
> file names so that they can coexist on PyPI or local archives - which<br>
> is where wheel tags come in. I'd be in favour of not using semantic<br>
> tags for this - rather hash the deps or something and just make a<br>
> unique file name. Use actual metadata for metadata.<br>
><br>
> @Nathaniel "I know that one unpleasant aspect of the current design is that the<br>
> split between egg-info and actual building creates the possibility for<br>
> time-of-definition-to-time-of-use bugs, where the final wheel<br>
> hopefully matches what egg-info said it would, but in practice there<br>
> could be skew. (Of course this is true in any system which represents"<br>
> - actually see <a href="https://bugs.launchpad.net/pbr/+bug/1502692">https://bugs.launchpad.net/pbr/+bug/1502692</a> for a bug<br>
> where this 'skew' is desirable: for older environments we want<br>
> tailored deps with no markers, for anything supporting markers we want<br>
> them - so the wheel will have markers and egg_info won't.<br>
><br>
> @Nathaniel "<br>
> (Part of the intuition for the last part is that we also have a<br>
> not-terribly-secret-conspiracy here for writing a PEP to get Linux<br>
> wheels onto PyPI and at least achieve feature parity with Windows / OS<br>
> X. Obviously there will always be weird platforms -- iOS and FreeBSD<br>
> and Linux-without-glibc and ... -- but this should dramatically reduce<br>
> the frequency with which people need sdist dependencies.)" - I think a<br>
> distinction between sdist and binary names for dependencies would be a<br>
> terrible mistake. It will raise complexity for reasoning and<br>
> describing things without solving any concrete problem that I can see.<br>
><br>
> @Nathaniel "I guess to make progress in this conversation I need some<br>
> more detailed explanations. I totally get that there's a long history<br>
> of thought and conversations behind the various assertions here like<br>
> "a sdist is fundamentally different from a VCS checkout", "there must<br>
> be a 1-1 mapping between sdists and wheels", "pip needs sdists that<br>
> have full wheel metadata in static form", and I'm barging in from the<br>
> outside with no context, but I literally have no idea why the specific<br>
> design features you're asking for are desirable or even viable. Right<br>
> now if I were to try and write the PEP you're asking for, then the<br>
> rationale section would just be "because Donald said so" over and over<br>
> :-). I couldn't write the motivation section, because I don't know any<br>
> problems that the PEP you're describing would fix for me as a package<br>
> author (which doesn't mean they don't exist, but!)." -- VCS trees are<br>
> (generally) by-humans for humans. They are the primary source of data<br>
> and can do thinks like inferring versions from commit data. sdists are<br>
> derived from the VCS tree and can include extra data (such as<br>
> statically defined version data). Wheels are derived from a tree on<br>
> disk and can (today) be built from either VCS trees or sdists. I'm not<br>
> sure that forcing an sdist step is beneficial - the egg-info step we<br>
> have today is basically that without the cost of compressing and<br>
> decompressing potentially large trees for no reason.<br>
><br>
> @Jeremy "An sdist is an installable package which just happens to _look_ a<br>
> lot like a source release tarball, but trying to pretend that<br>
> downstream packagers will want to use it as such leads to a variety<br>
> of pain points in the upstream/downstream relationship. For better<br>
> or worse a lot of distros don't want generated files in upstream<br>
> source code releases, since they need to confirm that they also ship<br>
> the necessary tooling to regenerate any required files and that the<br>
> generated files they ship match what their packaged tooling<br>
> produces." - Well, pbr doesn't work if you just tar up or git export<br>
> your VCS tree: it requires the chance to add metadata. And while<br>
> distros have whinged about pbr in a number of contexts, that hasn't<br>
> been one so far. Downstreams are pretty used to receiving tarballs<br>
> with generated files in them - as long as they *have the option* to<br>
> recreate those, so the source material isn't lost. [And for version<br>
> data, 'grab from git' is a valid answer there']. OTOH perhaps<br>
> ftpmaster just hasn't noticed and we're about to get a bug report ;)</p>
<p dir="ltr">another interesting use case for [not-] pip:<br>
<a href="https://github.com/mitsuhiko/pipsi">https://github.com/mitsuhiko/pipsi</a></p>
<p dir="ltr">> _______________________________________________<br>
> Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/distutils-sig">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
</p>