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

101–110 of 171 posts

Re: Announcing Pipenv

#101

Post by kalefranz »

daenney wrote: post #65
schlumpf wrote: post #55

Earlier quoted context omitted.

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.

The miniconda bootstrap of conda is ~20-30 MB (compressed) depending on platform. It contains only conda and its dependencies, like python and requests. It's how you install conda if you want only conda. The 400 MB number is for the Anaconda Distribution, which is a self contained, single-install, get-all package primarily aimed at scientists and engineers.

Re: Announcing Pipenv

#102

Post by jjawssd »

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…

pyenv

Re: Announcing Pipenv

#103

Post by jjawssd »

JeremyBanks wrote: post #99

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

Isn't `python` in Ubuntu a Python 3?

Re: Announcing Pipenv

#104

Post by olejorgenb »

Seems to be a python specific nix-shell like tool?

With nix[OS] you just run `nix-shell -p python[2,3] python[2,3]Pacakges.numpy ...` to get an environment with the required packages.

Of course this requires that the python library is packaged in nix, but in my experience the coverage is quite good, and it's not very hard to write packages once you get the hang of it.

It also possible (but currently a bit clumsy in some ways) to set up named and persistent environments.

Re: Announcing Pipenv

#105

Post by jjawssd »

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

No, but you could be using pyenv instead of the system package manager because it is far cleaner

Re: Announcing Pipenv

#106

Post by olejorgenb »

zoul wrote: post #33

I always wonder if this could be done once and for all languages, instead of Ruby making bundler, Haskell Cabal sandboxes or stack, Perl Brew, etc. Is this where Nix is going?

In some way, absolutely.

You can easily get a nice isolated python environment with some packages in nix without using pip, pyenv, etc. `nix-shell -p python pythonPackages.numpy ...`

So far I think it works quite well for most languages as long the needed packages are in nixpkgs.

Some of the tooling could be better, but the underlying model seems sound.

I'm not really convinced language-specific package managers are needed. Nix isn't perfect yet, but it has come a long way.

Re: Announcing Pipenv

#107

Post by olejorgenb »

toyg wrote: post #45
zoul wrote: post #33

I always wonder if this could be done once and for all languages, instead of Ruby making bundler, Haskell Cabal sandboxes or stack, Perl Brew, etc. Is this where Nix is going?

You make it one tool, and sysadmins will instantaneously lock it down. These package managers, in most cases, are developer tools built to get around system-wide locks on libraries; the more you centralize them, the more likely it is they will get locked down, and then someone will build tools to get around that, and so on and so forth.

As one of the few package mangers, nix can be used without root access.

Re: Announcing Pipenv

#108

Post by anuragsoni »

jjawssd wrote: post #103
JeremyBanks wrote: post #99

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

Isn't `python` in Ubuntu a Python 3?

Not yet. At least on ubuntu 16.10 python still defaults to `python2`

Re: Announcing Pipenv

#109

Post by emeraldd »

iheredia wrote: post #95
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

Is that true? His command would evaluate the path at the time which is run, but yours seems to evaluate the path at the time python3.5 is run. Subtle, but very different results.

Re: Announcing Pipenv

#110

Post by sametmax »

Diederich wrote: post #92
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.…

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.

No. Does it build a dependency graph and output your the best path to upgrades ?
Post reply on HN