documentation/question: package publishing

problem

pipenv’s opening documentation here is worded such that I expected that I could actually package and ship my project with pipenv.

1. can i package/publish my project with pipenv?
2. if so, how? the docs and issues from what I’ve searched omit mention of this

anyway, thanks! so far feels like a much better UX that past tooling

Describe your environment

n/a

Expected result

pipenv publish to kick off a publish cycle

Actual result

docs and/or feature not present

Steps to replicate

n/a

[ncoghlan]

Folks may also want to read http://www.curiousefficiency.org/posts/2016/09/python-packaging-ecosystem.html#my-core-software-ecosystem-design-philosophy.

Tightly coupling publishing tools to installation tools is useful for forming an initial tight-knit coherent publishing community, and for exploiting network effects as a commercial platform operator, but it’s an approach with a limited lifespan as an ecosystem grows and the diversity of deployment and integration models increases.

For Python, the first phase of that lasted from around 1998->2004 (build with a distutils based setup.py, publish as a tarball if you had no dependencies, or as a Linux distro package if you wanted dependency management), the second phase from around 2004-> 2008 (build with a setuptools based setup.py, install with easy_install), and we’re currently still in the third phase (build with a setuptools based setup.py, install with pip).

One key current focus of ecosystem level work is on eliminating the requirement for published projects to include a setup.py file at all. Once that’s the case, then it would indeed be reasonable for pipenv to define a PEP 517 build backend that allowed Pipfile-based applications to be published directly to PyPI. It wouldn’t involve a setup.py file, though, it would be a pyproject.toml file that looked something like:

[build-system]
requires = ["pipenv"]
build-backend = "pipenv.publish:build" # Actual API name TBD

[cdaringe]

@jtratner, sure that looks like it could work. i may try that soon!

to achieve the goal of publishing a library and an executable script, the proposed solution requires 3 tools and a handful of associated files, where neighboring technology stacks would require 1 tool and 1 or 2 files. every time i come back to python i feel lost about what the right tool for the job is. easy_install, pip, pipenv, …make, pip_install, venv/virtualenv, pyenv, etc. they are all sorta kinda related, but all have unique roles. in node, you need just one thing–npm (debatably nvm too, but installing deps next to your source makes it much less relevant in comparison to python). npm has warts, but the consolidation down to one simple tool for library authoring, executable authoring, and build scripts i feel has been underplayed in that community’s explosive growth.

i was hoping that this tool would be the npm of python, and have the [pyenv|nvm|etc] bit figured out too. instead, it’s a sort of hybrid. in node speak, it’s nvm + 1/3 of the npm client. i gather from the above remarks that the python community has grown comfortable with what they have–throw more tools at it (with no snark intended). this all works, but i think the dev experience would be improved by merging/consolidating all of the functionality.