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

Pipenv: promises a lot, delivers very little

chriswarrick.com

Post reply on HN
Print view View original

141–150 of 229 posts

Re: Pipenv: promises a lot, delivers very little

#141

Post by EdwardDiego »

icebraining wrote: post #74
adaszko wrote: post #21

Earlier quoted context omitted.

With pip for instance, it often happens that a transitive dependency gets updated inadvertently breaking your code. This follows from the assumption that all packages follow semantic versioning perfectly and keep backward compatibility where they should. This is not the case in practice and experience has shown it is unrealistic to have that assumption. A better way is to rely on exact versions of packages (up to a s…

How would you updated something inadvertently?

Transitive dependencies... it seems to be common in Python libs to express dependencies using version ranges - but then version 18.1 breaks something that worked under 18.0 - which isn't what you'd expect if it followed semver.

Re: Pipenv: promises a lot, delivers very little

#142

Post by EdwardDiego »

> Another issue with this tagline was the Python.org and official parts. The thing that made it “official” was a short tutorial [1] on packaging.python.org, which is the PyPA’s packaging user guide. Also of note is the Python.org domain used. It makes it sound as if Pipenv was endorsed by the Python core team. PyPA (Python Packaging Authority) is a separate organization — they are responsible for the packaging parts (including pypi.org, setuptools, pip, wheel, virtualenv, etc.) of Python. This made the endorsement misleading.

Hmm I'll admit I only started using pipenv because of that... "endorsement".

Re: Pipenv: promises a lot, delivers very little

#144

Post by icebraining »

EdwardDiego wrote: post #140
bobbyi_settv wrote: post #94

Earlier quoted context omitted.

What's the "one tool" for Java? Is it Maven? Ivy? sbt? Gradle? You may say some of those are "build tools" rather than dependency tools, but I don't see how it's different than what we are discussing in Python. My Java app declares its dependencies in a build.sbt file using Scala syntax and has them cached in an Ivy directory. Yours declares them in a pom file using XML syntax and has them cached in a Maven directory…

We don't need lockfiles in Java land because we generally use version ranges very carefully and rely on package developers following semver - and we certainly don't use "just whatever the latest release is, dude" like shown in the example Pipfile: https://pipenv.readthedocs.io/en/latest/basics/#example-pipf... (the asterisks) I get why Python needs lockfiles, but goddamn, that need is a symptom of the mess of managin…

rely on package developers following semver

Well, that seems naive. Almost 1/4th of Maven Central libraries broke binary compatibility in patch updates: https://avandeursen.com/2014/10/09/semantic-versioning-in-ma...

Netflix, at least, doesn't agree that Java doesn't need lockfiles: https://github.com/nebula-plugins/gradle-dependency-lock-plu...

Re: Pipenv: promises a lot, delivers very little

#145

Post by toyg »

president wrote: post #95

Honest/naive question - why has it been so hard to create a good package management system for Python? Couldn't someone do a straight port of one that has been proven to work well from a different language?

A bit of politics, a bit of genuinely different requirements across the ecosystem. Unlike most other languages with a single packaging tool, Python serves very different niches at the same time: webdev, sysadmin, embedded, datascience, fat clients, libraries, bindings, etc etc. They all have different usecases and concepts of “packaging tool”. When a new tool emerges, it usually serves one niche better than others; the other elements of the ecosystem push back, and a new tool is built... repeat ad infinitum.

This does not happen with languages where a single niche accounts for most of the use, so a broad consensus is easier to achieve. The closest to Python is Java, but that is traditionally steered top-down (but still has competing toolchains, e.g. ant/maven/gradle).

Pipenv in particular has some additional problems that were completely self-inflicted (namely, a famous developer abusing his popularity to push an incomplete implementation as blessed).

Re: Pipenv: promises a lot, delivers very little

#146

Post by holografix »

avip wrote: post #53
holografix wrote: post #49

Earlier quoted context omitted.

can you get VSC code completion to use a python interpreter in a Docker container?

I can't! In fact that was my main motivation in posting that, maybe a wiser HNer will enlighten me.

Damn was hoping something had changed in the last 6 months when I had a look! :-)

Re: Pipenv: promises a lot, delivers very little

#147

Post by ergo14 »

openbasic wrote: post #20
dfee wrote: post #2

I was sorely disappointed with pipenv, and transitioned to poetry [1], with which I’ve been very satisfied. There is also some commentary in the README on the design decisions re: pipenv [3]. Contrary to the author's perspective on poetry using poetry-specific sections of pyproject.toml, that's actually the proper implementation (and expected usage) coming out of PEP-518. I also am a big fan of pyenv [3] but that’s o…

Does poetry create a local vendor folder like "node_modules" or "vendor"?

That is the role of virtual env if I understand correctly what you are asking about.

Re: Pipenv: promises a lot, delivers very little

#148

Post by cwp »

president wrote: post #95

Honest/naive question - why has it been so hard to create a good package management system for Python? Couldn't someone do a straight port of one that has been proven to work well from a different language?

The problem is that (just about) all python packages express their dependencies with a script called setup.py. To figure out the full transitive closure of dependencies you have to walk the graph, downloading and executing setup.py scripts. First of all, that's slow.

But worse, setup.py is a python script with access to the full power of python. It can crash. It can be slow. It can loop forever. It can have dependencies of its own. It can require specific versions of python. It can download stuff from the internet. It can do anything.

If you wanted to implement something like npm for python, you'd have to convince all the python package maintainers to write and test package.json files for all their packages. Even if they were willing and enthusiastic about that, you'd have a chicken and egg problem because nobody could test a package.json until all their dependencies had them.

Python has a such a plethora of packaging tools because people keep trying to solve the problem by writing better code. But the real problem is lack metadata. Python will always have a lousy packaging ecosystem because it relies on setup.py.

Re: Pipenv: promises a lot, delivers very little

#149

Post by INTPenis »

Skimming the comments in this thread I see firstly a lot of hate towards pipenv that I don't understand. I mean on a technical level, I don't understand what you're talking about.

Secondly, interspersed beteween the hate I could count at least 6 alternatives to pipenv.

So as a python user I don't know who to trust.

I stumbled across pipenv at a time when I was managing a "global" directory of virtualenvs instead of putting them inside each project dir.

So I could do source ~/.venvs/project/bin/activate because I was tired of having different .venvs inside project dirs.

Pipenv seemed like a welcome change and I especially liked doing pipenv run commands. I still run my dev servers with pipenv run. Keeps my environment clean.

Sourcing a virtualenv before would lock that shell to only working with one project, one environment.

I have noted some issues with pipenv, the first was in ansible deployment but it wasn't a show stopper.

The second issue I can't remember so it must have been fleeting.

As someone else pointed out, maybe it's for simple users like me who don't need to understand the advanced internals of Python.

Edit: Right! The 2nd issue was actually that I work with some services that are spread across three different git repos/projects. Maintaining a central virtualenv for multiple projects needed figuring out but I think I've resolved it by having a parent dir for the service where the virtualenv is created and then pipenv commands in the sub-dirs (git repos) use the parent virtualenv.

I've also noted some confusion in pipenv on whether it's using python3 or 2. A pipenv --two project might try to install packages using pip3 for some reason.

Lastly, a lot of the hate towards pipenv seems to be directed towards how it was launched and marketed. Which in my opinion has little to do with the tool and how it might help users with Python.

Open source has always been and will always be a wild ecosystem where the best tool floats to the top by word of mouth alone. So why be mad because someone used python.org to promote a tool when you can contribute your time and knowledge to promoting your favorite yourself.

I just don't like when there are too many options to choose from and I don't know which one is right for me. I guess time will tell. Also I don't really do CI/CD pipelines yet so maybe a lot of issues are unknown to me.

Re: Pipenv: promises a lot, delivers very little

#150

Post by sametmax »

pseudalopex wrote: post #133
sametmax wrote: post #109

Earlier quoted context omitted.

- there is nothing you can do with pyproject.toml that you can't with setup.cfg. E.G: you are not forced to use setuptools to use setup.cfg. Any tool supporting pyproject.toml could support setup.cfg as easily, since it's a documented plain text format. It's a political decision. - there are things you can't do with pyproject.toml you can with setup.cfg. E.G: you can't use pyproject.toml with legacy tools, or with ju…

The format of setup.cfg is whatever configparser accepts, which is different in different versions of Python.

First, it managed to work fine for setuptools for 2 years accross all recent python versions. That's because the differences are minor and edge cases. Try to use pyproject.toml in most CI toolchain just for fun...

Second, the format of setup.cfg is defined in a documentation already, so there is a reference outside of configparser. Yes, the low level format is not explicitly defined (although it is implicitly): so let's do define it instead of creating a new one.

Third, it's still a much easier and saner task to rafine the definition of setup.cfg than to create a new standard. I don't even understand how this is controversial, espacially among people in the computing world, where we had those kind of problems for decades and we know the pros and cons, and consequence of this.

The "I add my little format because it's pure and better and current things suck" falacy is such a stereotype we should all be able to recognize it from miles away from nowaday.

Post reply on HN