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

71–80 of 171 posts

Re: Announcing Pipenv

#71

Post by sametmax »

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/

I have a big doubt about Molinillo. The readme doesn't even link to a documentation.

Does it allow you to update one package or the executable version and get a list of all the stuff to update ?

Re: Announcing Pipenv

#72

Post by Kaizyn »

ghshephard wrote: post #39
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…

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…

Pip is built on top of setuptools/distutils, so you are using them without even knowing it.

Re: Announcing Pipenv

#73

Post by rplnt »

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…

> 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 because the path would end up being hundreds of characters long.

Re: Announcing Pipenv

#74

Post by Dowwie »

sametmax wrote: post #56
renesd wrote: post #36

Earlier quoted context omitted.

I think python packaging has gotten LOTS better in the last few years. I find it quite pleasurable to use these days. From binary wheels (including on different linux architectures), to things like local caching of packages (taking LOTS of load off the main servers). To the organisation github of pypa [0], to `python -m venv` working. Also lots of work around standardising things in peps, and writing documentation fo…

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

Re: Announcing Pipenv

#75

Post by edblarney »

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…

"This is great, but sometimes I think that python needs a new package manager from scratch"

Ha, that's what I came here to say!

Or better - a new packaging paradigm.

Maybe it's extremely uncool to say ... but I think Java still has the best packaging paradigm of all languages. Jars rule. Of course 'gradle' is kind of a confusing mess so they don't have dependencies worked out very well ...

Nevertheless I do feel that Python's packaging and dependency/versioning woes create a much bigger systematic problem than many realize.

Kudos to the author though ...

Re: Announcing Pipenv

#76

Post by yjftsjthsd-h »

Kaizyn wrote: post #72
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…

Pip is built on top of setuptools/distutils, so you are using them without even knowing it.

Not atypical; I'm pretty sure apt uses dpkg, and dnf and yum use rpm underneath.

Re: Announcing Pipenv

#77

Post by crdoconnor »

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

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

Re: Announcing Pipenv

#78

Post by crdoconnor »

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…

>it's frustrating to deploy because its non-relocatable

I've tried relocating node_modules. It's a recipe for pain and tears.

I don't see why it's a big problem that virtualenv is a package rather than built in.

I also haven't had much of a problem with virtualenv not being relocatable. If you want it somewhere else, just build it there.

>Also notable, IMO, is the lack of a tool like rbenv

Ummmmm the creator of rbenv also created pyenv.

Re: Announcing Pipenv

#79

Post by sjellis »

renesd wrote: post #36
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 think python packaging has gotten LOTS better in the last few years. I find it quite pleasurable to use these days. From binary wheels (including on different linux architectures), to things like local caching of packages (taking LOTS of load off the main servers). To the organisation github of pypa [0], to `python -m venv` working. Also lots of work around standardising things in peps, and writing documentation fo…

This is actually one of the big problems, I think: Python packaging involves knowing a number of different things and reading various resources to get the full picture.

Recently, I built a small CLI tool in Python, and learned all of the bits needed to build, test and package my application "the right way". I knew Python syntax before, but it was a lot of effort to set this up. The difference in the experience between Python and Rust or .NET Core is actually shocking, and most it isn't down to anything that Python couldn't do, just the current state of the tooling.

Re: Announcing Pipenv

#80

Post by pkd »

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…

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

Post reply on HN