Recommend dependency version management tooling based on use case

[ncoghlan]

Similar to the problem in #118 with regards to virtual environment management, our current tooling recommendations don't provide a pointer to higher level dependency version management tools like pipenv or pip-tools, they only refer to pip itself.

While we don't want to overwhelm people with choice, I think we're currently doing folks a disservice by letting them think pip is all there is, rather than guiding them towards more opinionated higher level tooling:

• pipenv: web application development (and potentially other forms of application development)
• pip-tools: general application development (useful when pipenv doesn't align with your needs)
• conda: language-independent cross-platform package (useful when you have extensive external dependencies)

[ncoghlan]

briefcase would also be worth mentioning for cross-platform native app deployments (including web & mobile): https://pypi.python.org/pypi/briefcase

[kennethreitz]

I'd love to see pipenv referenced! I think that'd do the community a great service (and pip-tools as well, of course).

I don't do a good job of this myself on python-guide — I just point people to using pip. However, I just updated all my personal projects to recommending installation via pipenv last night. So, slowly encouraging adoption in that area.

---

My thoughts are that this is a good idea, if the information is presented simply, much in the way that Python-Guide presents the list of web frameworks:

http://docs.python-guide.org/en/latest/scenarios/web/

Note that it doesn't include every possible option, and it effectively instructs the user which framework to use.

[ncoghlan]

@kennethreitz Heh, your advice on Django vs Flask is almost exactly how I was planning to describe the distinction between pipenv and pip-tools (i.e. if you don't have a strong opinion yourself, then you want to start with pipenv, since that's more comprehensive, whereas pip-tools is a better option if you need or want more control over the precise dependency management behaviour).

[kennethreitz]

✨🍰✨

[theacodes]

From @ncoghlan in https://github.com/pypa/python-packaging-user-guide/pull/369/files/b102d60fe4d8ac3cf6fce53fd5bf5f159d2f7fc8#r136228176

Suggested initial set of links:

• briefcase: briefcase is a tool that focuses on defining applications as Python packages, and then using that package definition to generate native application installers for popular client operating systems
• pex: PEX is a single-file distribution format for executable Python virtual environments as zip archives containing a __main__.py file. Their main runtime requirement is that a suitable Python interpreter be available on the system running the application.
• pipsi: Similar to pex, pipsi aims to run applications in self-contained virtual environments. Unlike pex, it generates these virtual environments dynamically inside the user's home directory for applications available as Python packages.
• pew: the underlying virtual environment manager used by pipenv (this is a lower level tool that offers more flexibility in where, when, and how virtual environments are created and updated)
• pip-tools: automated requirements.txt file management that distinguishes between abstract dependency combinations that are expected to work, and the specific pinned versions that will be tested and/or deployed (this is a lower level tool that offers more flexibility in when and how dependencies are installed and updated)
• conda: conda is a "cross-platform platform" that manages the Python interpreter and external binary dependencies in addition to managing Python modules. It is most useful in situations where it is easier to ensure that the conda package manager is preinstalled than it is to ensure that a suitable Python version is available.

And then make a note that the above list only covers cross-platform tools, and there are also other platform specific options available if users are only interested in a limited set of platforms.

[ncoghlan]

#370 adds this as a set of links at the end of the new pipenv tutorial.

However, a better overall structure is likely to be:

• create new "Dependency Management" and "Application Bundling" discussion topics (see Cover "Bundled Applications" as an additional topic #267 for the latter)
• mention pipenv & pip-tools directly on the "Recommended Tools" page in a new Dependency Management section, with a link to the full discussion page
• link to both the Dependency Management and Application Bundling discussions from the alternatives section at the end of the pipenv tutorial (rather than listing the alternatives inline as they are in my initial PR)

[ncoghlan]

I closed #370, but have kept the branch so we can easily re-use the content from fbb4864

[theacodes]

Sounds good. Thank you. :)

…

On Wed, Aug 30, 2017, 8:15 PM Nick Coghlan ***@***.***> wrote: I closed #370 <#370>, but have kept the branch so we can easily re-use the content from fbb4864 <fbb4864> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#367 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAPUc5Uk-H0aqjbrQpbj8JfzBMW5HRvnks5sdiVlgaJpZM4PA0tV> .

[ncoghlan]

Another one worth mentioning (from #375): https://github.com/ofek/hatch

That goes several steps further than pipenv, and gives you a full project management toolkit for software publishers aiming to release through PyPI, not just consuming components from PyPI for use as part of an application or development & testing environment.

[kennethreitz]

Hatch looks very cool, and definitely something worth mentioning — however, it also looks very complex, skimming the README. Far from a simple tool — it just does a lot. Looks like @ofek put a lot of work into it :)

[ofek]

Based on advice from @kennethreitz I have significantly uncluttered the readme https://github.com/ofek/hatch#usage

[ncoghlan]

I've included a link to both pip-tools and hatch at the end of the new pipenv dependency management tutorial in #402

However, I still think a broader discussion article about the trade-offs between the various options would make sense.

[willingc]

I would be willing to write a documentation page about using conda-forge and PyPI together. It would focus more on the things available than promoting one over the other.

[cjerdonek]

FYI, back in April I posted a comment that lists the current mentions of conda in the packaging docs, when a similar discussion was happening: https://discuss.python.org/t/drawing-a-line-to-the-scope-of-python-packaging/883/50?u=cjerdonek

It could be useful for consolidating things and deciding where new content should go / what needs updating.

[Tecktron]

I would love to see some reasons why and in what cases one should use these tools. Not just the (dis)advantages of each other but also include just using venv from the standard lib and pip. I have a very hard time trying to figure out why pipenv is the "preferred" choice, there's 0 explanation for a tool that, until very recently, wasn't updated for years.

Like pipenv is better for webapps dev but why? Having all these tools without listing reasons and use cases is very un-pythonic IMO, referencing the Zen of Python that "[t]here should be one-- and preferably only one --obvious way to do it." This has stumbled far from that philosophy.

It's like saying ketchup is better than hot sauce. Is it tho? Maybe on fries, but certainly not nachos. Please explain your thoughts and reasoning when you make your case.