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

91–100 of 171 posts

Re: Announcing Pipenv

#91

Post by ProblemFactory »

sametmax wrote: post #88
crdoconnor wrote: post #77

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. 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 e…

It would be even better if the tool ran your project's tests when checking upgrade combinations.

Something that would say: "You can safely upgrade to Django 1.9.12. Upgrading to latest Django 1.10.5 breaks 20 tests."

Re: Announcing Pipenv

#92

Post by Diederich »

sametmax wrote: post #42
ghshephard wrote: post #39

Earlier quoted context omitted.

Okay - maybe I'm missing something, but pip is the only Python package manager I've ever used. And it's basically "pip install xxx", "pip install --upgrade xxx", "pip show xxx", "pip list", "pip uninstall xxx" I'm curious what I've been missing about pip that makes it problematic - I've never used the other tools you mentioned (setuptools/distutils/ez_install) - so I can't comment on them, but, on the flip side, I've…

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

Honest question: have you seen how the Perl world handles this stuff? Now that I've mostly moved over to Python, the Perl experience (overall package mgmt) seems much, much better.

Note, it doesn't feel terrible in Python land, to me at least. But it was almost a joy working with Perl's packaging system.

Re: Announcing Pipenv

#93

Post by crdoconnor »

sametmax wrote: post #88
crdoconnor wrote: post #77

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. 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 e…

>That doesn't guaranty your setup will work.

Nothing guarantees your setup will work.

Re: Announcing Pipenv

#94

Post by ellisv »

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…

I don't disagree but your suggestion sort of reminds me of this xkcd: http://xkcd.com/927/

Re: Announcing Pipenv

#95

Post by iheredia »

helb wrote: post #86

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

Just a comment. Your command is equivalent to

  $ virtualenv -p python3.5 .venv

Re: Announcing Pipenv

#96

Post by StavrosK »

sametmax wrote: post #88
crdoconnor wrote: post #77

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. 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 e…

How can you have an upper bound on compatibility? When a library is released, it knows that it works with version 1.3.2 with its dependency, but how can it ever know it doesn't work with 1.4, unless the developer goes back and re-releases the app?

Re: Announcing Pipenv

#97

Post by nilliams »

rplnt wrote: post #73
cderwin wrote: post #51

Earlier quoted context omitted.

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…

> like node [...] have figured out how to handle non-global dependencies Node would be the last place I'd look for a good solution in. Not sure if there was some progress recently, but it was hell some time back. Modules were huge, taking thousands of other modules with them, majority of those being duplicates. There was no deduplication, no version wildcards I believe either. It wouldn't even work with some tools be…

Since npm 3 (about 18 months ago), the node_modules dir tree is now 'flat' and de-duped (where possible).

There have always been version wildcards as far as I know. Long paths caused by the deeply nested tree were a problem in Windows only, addressed (I believe, I can't find open issues on it) by the flattening in npm 3.

Re: Announcing Pipenv

#98

Post by sametmax »

StavrosK wrote: post #96
sametmax wrote: post #88

Earlier quoted context omitted.

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

How can you have an upper bound on compatibility? When a library is released, it knows that it works with version 1.3.2 with its dependency, but how can it ever know it doesn't work with 1.4, unless the developer goes back and re-releases the app?

Python 2.7 Python 3

Re: Announcing Pipenv

#99

Post by JeremyBanks »

> Otherwise, whatever $ which python will be the default.

This is a bit strange because the python binary is always supposed to be Python 2. The Python 3 binary is supposed to be named python3. Some distributons don't follow this, but they're the weird non-conformant ones; it's not a behaviour that should really be relied on.

Re: Announcing Pipenv

#100

Post by scrollaway »

sametmax wrote: post #42
ghshephard wrote: post #39

Earlier quoted context omitted.

Okay - maybe I'm missing something, but pip is the only Python package manager I've ever used. And it's basically "pip install xxx", "pip install --upgrade xxx", "pip show xxx", "pip list", "pip uninstall xxx" I'm curious what I've been missing about pip that makes it problematic - I've never used the other tools you mentioned (setuptools/distutils/ez_install) - so I can't comment on them, but, on the flip side, I've…

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

Oh my god, you've described every single one of my issues with Python packaging.

The whole setup.py/setup.cfg situation really is ridiculous. Having to import the __version__, read() the README, no markdown support on pypi, MANIFEST / MANIFEST.in files, tox.ini, what a mess.

Post reply on HN