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

81–90 of 171 posts

Re: Announcing Pipenv

#81

Post by bge0 »

ploggingdev wrote: post #32
cderwin wrote: post #24

This is great, but sometimes I think that python needs a new package manager from scratch instead of more tools trying to mix and mash a bunch of flawed tools together in a way that's palatable by most of us. Python packaging sucks, the whole lot of it. Maybe I'm just spoiled by rust and elixir, but setuptools, distutils, pip, ez_install, all of it is really subpar. But of course everything uses pypi and pip now, so…

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

I actually really love `Cargo` : the rust package manager.

Re: Announcing Pipenv

#82

Post by igravious »

pkd wrote: post #80
mhw wrote: post #69

Earlier quoted context omitted.

> 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 v…

> 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 You can also accomplish the same using gemsets which are provided by rvm.

Using RVM is not always an option and some might consider it an anti-pattern.

Re: Announcing Pipenv

#83

Post by igravious »

K0nserv wrote: post #63
sametmax wrote: post #47

Earlier quoted context omitted.

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/

This is exactly what I was trying to get at with my original comment. There needs to be a lot more sharing of package management tools and techniques across language boundaries. Generic platform- and language-agnostic tools and algorithms are a step in the right direction!

Re: Announcing Pipenv

#84

Post by wyldfire »

I haven't really used requirements.txt because I found that I could install 'extra' and 'test' specific content based on args to setup() in my setup.py. It seems more like the Right Thing than requirements.txt, from what I can tell.

At first glance, this doesn't seem to offer anything beyond what I already see from setup(). What am I missing?

It's unfortunate that CPython gave us distutils and took a very long time to converge on a built-in successor (setuptools?) that gives the right composability.

Re: Announcing Pipenv

#85

Post by igravious »

mhw wrote: post #69
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…

> 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 v…

Great to here you also do what I do with the path config variable. I was just reading the documentation and Bundler has an opinion about deployment as well. I must look into that. I will also start making sure I am using/setting .ruby-version .

Re: Announcing Pipenv

#86

Post by helb »

> --three / --two Use Python 3/2 when creating virtualenv.

I use Python 2.7, 3.4, and 3.5 on various projects. Is there a way to choose between 3.4 and 3.5 using Pipenv? I'm using something like this with virtualenv:

  $ virtualenv -p `which python3.5` .venv

Re: Announcing Pipenv

#87

Post by sametmax »

Dowwie wrote: post #74
sametmax wrote: post #56

Earlier quoted context omitted.

+1. Relatively to what we have before, it's so much better. But compared to the JS/Rust ecosystem, we are behind. Now it's hard to compete with JS on some stuff : it's the only language in the most popular dev plateform (the web) and it has one implicit standardized async model by default. It's hard to compete with rust on some stuff : it's compiled and is fast, can provide stand alone binaries easily and has a check…

It was definitely your fault. Thanks for nothing.

:) In the open source world, and given my skills, I always feel a bit responsible when a tool doesn't exist.

Re: Announcing Pipenv

#88

Post by sametmax »

crdoconnor wrote: post #77
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.…

>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. There's pip-tools.

pip-tools doesn't solve the problem at all. It will update things to the last up to date version, cascading from package to package.

That doesn't guaranty your setup will work.

Dependency management suppose to create a graph of all requirements, lower and upper versions bound for the runtime and the libs, and find the most up to date combination of those.

If a combination can't be found, it should let you know that either you can't upgrade, or suggest alternative upgrade paths.

pip-tools will just happily upgrade your package and let you with something broken, because it's based on pip which does that. They don't check mutually exclusive dependencies versions, deprecation, runtime compatibility and such. And they don't build a graph of their relations.

Re: Announcing Pipenv

#89

Post by throw2016 »

I think an app should not expose end users to its dependencies. That leaves the end user with a lot of pain figuring out versions of dependencies and god forbid you need to compile some dep then you need a build environment and its dependencies any of which can fail in this chain leaving a very unpleasant and even hostile end user experience.

Ruby and Node apps are particularly guilty of this pulling in sometimes hundreds of packages some of which need compilation. Compare that to a Go binary which is download and use. These things can get very complicated very fast even for developers or system folks let alone end users who may not be intimately familiar with that specific ecosystem.

Re: Announcing Pipenv

#90

Post by sametmax »

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…

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.

Post reply on HN