News for hackers. Stuff that matters.
Re:Announcing Pipenv by icebraining on Monday January 23, 2017 @02:46AM (#13460572)
I've always found the whole virtualenv stuff so superfluous. Do we really need all the machinery with shell scripts and static paths?

We just use a directory where we keep our dependencies. It's a matter of:

    mkdir libs
    pip install -t libs <package>
    # then to run
    PYTHONPATH=libs python app.py
From what I can tell, this accomplishes everything a venv does (except bringing the Python interpreter itself along) without requiring any extra tools or conventions to learn.
Re:Announcing Pipenv by istoica on Monday January 23, 2017 @04:23AM (#13460937)
As you pasted-it, it does not accomplish venv:

  - you still need to change PYTHON_PATH to recognize libs from `libs`
  - packages have bin scripts sometimes that most likely, will be needed by the project
A more proper command: - pip install -t ./libs --install-option="--install-scripts=./bin"

But still, does not solve the PYTHON PATH issue, it won't be solvable because all python cli tools and all scripts in ./bin must be aware of PYTHON_PATH including ./libs

This is what venv does and pip alone cannot easily solve, replicating an entire python environment that is aware of project local pip packages

Re:Announcing Pipenv by icebraining on Monday January 23, 2017 @05:12AM (#13461128)
My commands do set PYTHON PATH when running the app.

As for the cli tools, fair enough, but the packages I use with such tools/scripts are full applications, not dependencies to be included in another project. Which kinds of packages do you see as both dependencies and containing CLI tools?

Re:Announcing Pipenv by sametmax on Monday January 23, 2017 @09:08AM (#13462210)
No, you still don't have:

- ./bin. No commands for you.

- a way to specify your libs to a program not providing a way to set env var.

- isolation from the system stdlib. This will cause subtile bugs.

- a clean pip freeze. No deps listing.

- and hence a lock file.