[question] What is the recommended best practice for Pipenv and apps on Pypi?

[arnavb]

Throughout my learning about Pipenv, I have found various viewpoints about how one should handle applications that are supposed to be on Pypi (such as CLI apps). My initial thoughts are that one should get their dependencies from their Pipfile to their setup.py (because I want pip installs that are deterministic), but unfortunately, this is met with a "Do not do this.". I also understand why; The setup.py should only depend on setuptools and wheel; A dependency on Pipenv would not work.

That same thread later has a message from Kenneth Reitz which claims:

If I've explained this well enough, you can see that its just supposed to be the other way around.
You put your dependencies in install_requires, you put you package in the Pipfile, and then you get and environment, with a Pipfile.lock for reproducibility (as it will resolve and respect your package dependencies).

Ok..., so I should run a pipenv install -e ., and still place dependencies in my install_requires. I get reproducible builds with my Pipfile.lock, but..., what about pip? How do I get deterministic pip installs for a package without necessarily having to pin package versions AND not dependending on pipenv?

Looking at the repository for pipenv itself, I can't seem to find anything useful, as this package specifies its dependencies in setup.py (and nothing in packages of the Pipfile, not even an install of the current package through -e .). It's also evident that pipenv hasn't pinned package versions in your setup.py either, so the problems pipenv can solve aren't being solved for dependencies in this project.

Another idea: Given the new pyproject.toml, can I specify pipenv in the build requirements, and then import it into my project to add its dependencies to the setup.py?

Yes, I've read things like https://caremad.io/posts/2013/07/setup-vs-requirement/, but that doesn't necessarily help me, because it focuses on getting requirements.txt from setup.py, not the other way around, which would get me what I want.

Essentially, I want a way for pip install my_cli_package to get dependencies from the Pipfile.lock for that current package somehow. It's possible that my current way of thinking is completely wrong, and if it is, I would appreciate some clarification as to what I really should be aiming for (which is why I'm looking for the current best practice).

Thanks!

[uranusjr]

I mentioned this somewhere else, but can’t find my own comment at the moment, so I’m going to reiterate it briefly.

setup.py is not actually the only way to install packages (as you might already be aware, given the mention of pyproject.toml), just the default way. PEP 517 defines an interface for build systems to work with pip, and you can use build system declarations to replace setuptools (which uses setup.py) with another tool to specify how your package should be installed. Flit is currently the most prominent alternative.

“How can I install dependencies in Pipfile.lock from setup.py” is, therefore, a misled question. You can’t, and the real question should be “how can I declare my package to use Pipfile.lock as my dependency specification” instead. The answer is simple—you need an alternative build system that works that way, and declare you package to use it in pyproject.toml.

So how can you that build system I mentioned? You can’t, because it does not exist. See, Pipfile and Pipenv are not tightly-coupled; the former is a specification, and you can freely build libraries to interface with it. Pipenv, however, is only a tool that uses the specification, to handle application dependencies. It does not handle packaging Python libraries. And no-one has built a tool to do what you want—yet, until you build it. PEP 517 isn’t very difficult to implement, and Flit already figured out most of the things, so you can just copy-paste take inspiration from it.

Or, to put it short: Pipenv doesn’t do what you want, and likely won’t ever. Do it yourself.

[arnavb]

@uranusjr That's very helpful; thanks for the clarification!