On 16 January 2018 at 10:44, Nick Coghlan
Yes, that's deliberate. We want to target app developers as our initial audience, since library and framework developers have different needs (and for folks just starting out with library development, pipenv + the latest version of Python is actually fine - matrix testing only comes into play once folks actually want to support older versions, perhaps because the version they started out with is no longer the latest one).
Having that up front in the pipenv docs/webpage would probably help communicate the intention better. At the moment, it's pretty hard to find. And the general "pipenv is cool!" enthusiasm (which I agree with - it is :-)) tends to encourage people to try it out for whatever their use case is (hence Chris' original post). Also, there's a quite common recommendation around to "build your app as a library and have its main program as a console script entry point" - tools like pip, tox, pytest, pew, pipenv itself, etc take that approach, for example. So separating "app developers" and "library developers" still leaves a fairly large grey area.
Local build dependencies are within scope, but pipenv doesn't magically fix the development resource constraint problem :)
Understood - as I said, the pipenv devs were very helpful, it just took a bit of time to establish what I was trying to do, and that it *was* something that they saw the need to support. Actually implementing that support can take as long as it needs - I appreciate the "so much to do, so little time" problem. Better publicised "Python application development workflow" best practices might have helped save a little of our time in establishing I had a valid use case and they intended to support it but didn't yet. That's all I'm really saying. Paul