On 16 January 2018 at 10:03, Nick Coghlan <ncogh...@gmail.com> wrote: > On 16 January 2018 at 19:47, Paul Moore <p.f.mo...@gmail.com> wrote: >> I think that if the pipenv docs had some better guidance on what use >> cases it was intended to cover (and what it wasn't, in relation to the >> broader range of pip+virtualenv use cases) that would help people >> better understand its place in the ecosystem. > > That's fair, and making the PyPUG tutorial specifically about > *application* dependency management was an initial step in that > direction - for the library development use case, you're generally > going to step out of pipenv's world as soon as you try to run your > tests across multiple versions. > > The basic usage constraint is that pipenv expects you to control your > target Python version, and it expects you to have exactly one - to go > beyond that (as is needed for multi-version library support), you'll > still need to drop down to the lower level tooling, either skipping > the use of pipenv entirely, or else by using `pipfile lock > --requirements` to shift levels.
New subject as I don't want to hijack the original thread to rehash my old issue, but I do want to make a couple of points on this (and I agree, it's hard to find a good forum to discuss things like this as it stands). 1. "pipenv expects you to control your target Python version" - I'm not 100% sure what that means, but if it's saying "pipenv is only really for code that will only be used with a single Python version" then that's basically excluding a huge chunk of Python development. Specifically, library development of all forms. Admittedly my experience of what's "typical" is biased strongly by the communities I work with, but conversely the "writing standalone apps in Python" community doesn't really seem to have a web presence that we can promote pipenv through, so it's becoming visible via the "general Python development" community, which quite biased to libraries, and so is not the right target audience, from what you say. 2. My specific issues weren't outside that constraint - I *was* writing code that would only ever need to run under Python 3.6. My problem was the need for "local" build dependencies, which seems entirely within that use case. In fairness, the pipenv devs weren't totally against the functionality I needed, it's just not something they had considered important. Maybe the problem here is that there isn't a good set of "developing apps in Python" best practices (as opposed to the library development situation - use install_requires, test with tox, ...), so I didn't know the "recommended" solution to my problem, that pipenv would have been expecting me to use. Maybe it's a chicken-and-egg situation - the "best practice" is to use pipenv, but until pipenv gets to encounter all the various use cases, that "best practice" doesn't properly cover every situation... Paul _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
