On Wed, 19 Sep 2018 at 11:34, Tzu-ping Chung
I have the same experience with Pipenv as Nick’s. I would also guess another reason is the lack of knowledge—this is certainly my own before I get involved in Pipenv. There is barely any guide on how I should implement such a thing, and my developer’s instinct would tell me to look at a known implementation, i.e. pip. This also ties back to the problem that pip uses distlib internally barely at all—had it used more of it, people might be pointed to the right direction.
Migrating Pipenv’s internals from pip instead of distlib is actually the exact thing I am thinking about when I raised the question. There are, as mentioned, a lot of pieces missing in distlib. For example, distlib knows how to find a distribution, and how to install wheels, but not how a non-wheel distribution can be turned into a wheel. [1] It also has no functionalities on uninstallation. If I’m to glue together a working thing, I would likely need to copy/reimplement parts of pip, but where should they live? Do I add yet another layer above distlib to include them, or do I try to include them in distlib?
That's probably Vinay's call. IMO, whatever layer there is above packaging, it should do stuff like this.
Although distlib provides a nice basis, I feel it is still one layer below what most people want to do, e.g. install a thing by name (or URL). But would a three-layer design be too much, or should distlib have a high-level API as well?
I don't think a 3-layer approach is sensible, two layers is more than enough. Maybe not go all the way to "install something by name". Maybe APIs to * find what's available in a set of indexes/locations * check if a compatible wheel is in that list * make a wheel from a sdist * install a wheel It's hard to make something like this sound like anything other than put "pip into a library and make pip itself a thin shell round that library" though. At which point we come full circle round to the fact that the *reason* we don't support a pip API is that the cost of designing one, restructuring pip to expose (and use!) it, and creating documentation and tests to make sure that API is stable and properly supported, is huge. And we don't have the resources. It's not so much a technical/design or layering issue, it's really a resourcing and sustainability issue.
[1]: Also, while I’m having your attention—I’m trying to use the pep517 library as part of the solution to build an sdist into wheel, but I’m hitting a bug. Could you help review my PR? :p https://github.com/pypa/pep517/pull/15
It's not really me that can comment, you probably need Thomas. To clarify, even though I have commit rights on the pep517 project, I'm not really a project maintainer there. My interest in it is as a consumer from pip, which only uses the hook wrapper code. So this PR is in something I've not used or looked at closely. Pip does its own build isolation, ironically enough :-( Paul