On 16 January 2018 at 10:44, Nick Coghlan <ncogh...@gmail.com> wrote:
> 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 _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
