Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing Pipenv

kennethreitz.org

Post reply on HN
Print view View original

61–70 of 171 posts

Re: Announcing Pipenv

#61

Post by sametmax »

StavrosK wrote: post #59
sametmax wrote: post #42

Earlier quoted context omitted.

One things is a good dependency management. Right now if you want to upgrade your Python version, or one of your packages, it's a mountain of manual work. There is nothing in the stack helping you with the dependency graph. Another thing is providing a stand alone build. Something you can just ship without asking the client to run commands in the terminal to make it work. I use nuikta ( http://nuitka.net/ ) for this.…

I kind of want to take your list and write a tool that fixes (or, at least, automatically works around) all of these issues. Good job.

It actually could be several projects:

- one for graph deps;

- one for packaging;

- one for managing your project.

Then you can let people like Kenneth build a big friendly wrapper on top of it.

The only problem with those is that it must be pure Python. Otherwise you will have problems. Wheel are not bullet proof, and while you can get away with tinkering for dependencies, you can't with your package manager. It should work out of the box.

But creating "cargo for Python" is a very, very hard job. And nobody will remember you for it.

Re: Announcing Pipenv

#62

Post by istoica »

Finally someones does it! I was using: pip -t .pip in my code, avoiding virtual-env completely, but that was not enough and incomplete.

As this is not cross platform and it would be nice to switch between Linux/Windows while coding to maintain platform compatibility, can the virtualenv envs be created with a os platform & subsystem prefix ? for example, having multiple envs at once:

  - env/posix/bin/activate
  - env/nt/Scripts/activate.bat

Re: Announcing Pipenv

#63

Post by K0nserv »

sametmax wrote: post #47
igravious wrote: post #41

Earlier quoted context omitted.

Very similar. I think Pipenv improves on Bundler by leveraging Virtualenv and Ruby doesn't have a per project equivalent to Virtualenv that I'm aware of. You can set the path config variable of Bundler to not place the project Gems in a central location which I think is cleaner and try to remember to always do now. It would be _super_ interesting if the Python and Ruby communities got together to harmonize every last…

Actually we could also learn from: - the JS community. npm dependancy graph, webpack resolver and yarn performances; - the rust community like with cargo.

Bundler does proper dependency resolution using Molinillo[0] which is also used by CocoaPods[1]. This is definitely something that other package managers can stand to adopt.

0: https://github.com/CocoaPods/Molinillo 1: http://cocopods.org/

Re: Announcing Pipenv

#64

Post by istoica »

icebraining wrote: post #50
nejdetckenobi wrote: post #38

normally I use virtualenvwrapper and that makes a virtualenv directory for all virtualenvs you create with it. before that, I always create my projects' venvs inside my project hierarchy. I had a dilemma about it. But after all, you can not move your venv directory unless you use `--relocatable` option. So, anyone have a strong argument about creating venvs inside your project directory?

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 # 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 an…

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

#65

Post by daenney »

schlumpf wrote: post #55
sametmax wrote: post #42

Earlier quoted context omitted.

One things is a good dependency management. Right now if you want to upgrade your Python version, or one of your packages, it's a mountain of manual work. There is nothing in the stack helping you with the dependency graph. Another thing is providing a stand alone build. Something you can just ship without asking the client to run commands in the terminal to make it work. I use nuikta ( http://nuitka.net/ ) for this.…

This. Particularly the need for a minimum standard project structure. Pipenv shows its pedigree and looks like a great tool...that also overlaps significantly with conda. What are the use cases that Pipenv addresses better than/in lieu of conda?

You don't need to install (ana|mini)conda just to get a package manager, would be why I would use Pipenv over Conda. Miniconda alone requires somewhere close to 400MB of space and comes with a whole bunch of extra things I don't need just to manage packages and virtualenvs.

Re: Announcing Pipenv

#66

Post by sametmax »

schlumpf wrote: post #55
sametmax wrote: post #42

Earlier quoted context omitted.

One things is a good dependency management. Right now if you want to upgrade your Python version, or one of your packages, it's a mountain of manual work. There is nothing in the stack helping you with the dependency graph. Another thing is providing a stand alone build. Something you can just ship without asking the client to run commands in the terminal to make it work. I use nuikta ( http://nuitka.net/ ) for this.…

This. Particularly the need for a minimum standard project structure. Pipenv shows its pedigree and looks like a great tool...that also overlaps significantly with conda. What are the use cases that Pipenv addresses better than/in lieu of conda?

pipenv allow you to completly ignore the virtualenv. Like node_packages. It seems a detail, but giving a lot of python and js trainings, I came to realize newcomers needs little help like this.

Re: Announcing Pipenv

#67

Post by brennebeck »

cderwin wrote: post #51
ploggingdev wrote: post #32

Earlier quoted context omitted.

Just curious, what aspects of pip/virtualenv specifically do you find subpar in comparison to other languages' package managers.

I would look at this comment[0] by sametmax for a critique of pip. My main gripe with virtualenv is that it's required at all: other interpreted languages, like node and elixir for example, have figured out how to handle non-global dependencies without a third-party package. Beyond that, it's frustrating to deploy because its non-relocatable (in our build/deploy scripts at my last python job we had to use sed all ove…

> Also notable, IMO, is the lack of a tool like rbenv or rustup for python

Does pyenv not meet your needs there?

Re: Announcing Pipenv

#68

Post by bdukic »

mikhuang wrote: post #4

Uninstall by default removing everything seems a little scary. Otherwise looks really neat, looking forward to trying it

I wanted to comment on the same thing, IMHO something like `pip uninstall --all` would be a better choice. Great work otherwise!

Re: Announcing Pipenv

#69

Post by mhw »

igravious wrote: post #41
choxi wrote: post #5

Is this like Ruby's Bundler for Python? I've just been getting into Python and am really glad to see this, thanks for creating it!

Very similar. I think Pipenv improves on Bundler by leveraging Virtualenv and Ruby doesn't have a per project equivalent to Virtualenv that I'm aware of. You can set the path config variable of Bundler to not place the project Gems in a central location which I think is cleaner and try to remember to always do now. It would be _super_ interesting if the Python and Ruby communities got together to harmonize every last…

> Ruby doesn't have a per project equivalent to Virtualenv that I'm aware of.

The nearest equivalent is to place a file called '.ruby-version' in the top level directory, containing the version number of the Ruby you want to use. Version numbers come from https://github.com/rbenv/ruby-build/tree/master/share/ruby-b.... rbenv, chruby and rvm all support .ruby-version.

One difference from virtualenv is that the Ruby version managers share single installations of each version of Ruby. My understanding from occasional use of Virtualenv is that it copies the python installation into a new per-project subdirectory, which seems a bit wasteful to me.

> You can set the path config variable of Bundler to not place the project Gems in a central location which I think is cleaner and try to remember to always do now.

Yes, this is what I do. It gives me a shared 'clean' Ruby installation of the right version, plus a project-specific copy of all the gems the project depends on. To me this provides the best trade off between project isolation and not duplicating the whole world. You can set bundler up so this is done automatically by creating '~/.bundle/config' containing

    ---
    BUNDLE_PATH: "vendor/bundle"
    BUNDLE_BIN: ".bundle/bin"
(The BUNDLE_PATH one is the important one; see 'bundle config --help' for other options.)

Re: Announcing Pipenv

#70

Post by icebraining »

istoica wrote: post #64
icebraining wrote: post #50

Earlier quoted context omitted.

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 # 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 an…

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…

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?

Post reply on HN