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

One does not simply 'pip install'

ianwootten.co.uk

Post reply on HN
Print view View original

81–90 of 118 posts

Re: One does not simply 'pip install'

#81

Post by Karellen »

> Lets say you use the same package again, but theres been a new release with some additional features. When you upgrade your global Python to use it, you now need to ensure every project you’ve done now works with it. That’s annoying and unlikely to happen, what you’ll be left with is a broken build.

Wait, what?

Don't python packages generally use `semver` versioning, and ensure that upgrades in the same major version are backwards-compatible?

And that different major versions are co-installable?

Re: One does not simply 'pip install'

#82

Post by ploxiln »

mshockwave wrote: post #60
ploxiln wrote: post #50

Earlier quoted context omitted.

python3 includes "venv". If you don't have an existing preference, use that. python3 -m venv ../my-venv-dir # wherever you like . ../my-venv-dir/bin/activate pip install whatever you can close your terminal and "rm -r" the venv dir, and no trace will be left. (or you can just "deactivate" and use it again later)

The author mentioned venv in the article. Also I believe the parent comment is talking about the difficulties of choosing between different dependencies management solutions, venv among them, rather than the lack of (a good) one

Yes the article mentioned venv. And the parent said it's hard to choose. But the choice is easy: just use the basic built-in one. (Until you have a reason to use something else.)

It's a good general philosophy for software engineering: don't add stuff without good reason. There really is the potential to add infinite stuff these days - "awesome tools" and "best practices", without end. Individually they can help with particular problems you may have, but together they make a mess, and distract focus from the particular purpose of your software.

Re: One does not simply 'pip install'

#83

Post by scarface74 »

tyingq wrote: post #58

It's also interesting how things like AWS Lambdas, Graviton, etc, are exposing all the shortcomings of the various pip install, venv, poetry, etc, approaches. It's not impossible to figure it out, but you end up spending a lot of time to come up with something that works locally, within containers, inside a CI/CD system, and then deployed out across things like Lambdas, or non x64 machines. Then, after it's all worki…

At least with Lambda it really is easy, just use Serverless Application Model and when you do “sam build” choose “--use-container”. It will look at your CloudFormation template where you are referring to the local directory containing your source code and requirements.txt and download and build in the appropriate Docker container for your language, version and architecture.

It works great when you have native dependencies.

Re: One does not simply 'pip install'

#84

Post by wheelerof4te »

blandcoffee wrote: post #77
mshockwave wrote: post #60

Earlier quoted context omitted.

The author mentioned venv in the article. Also I believe the parent comment is talking about the difficulties of choosing between different dependencies management solutions, venv among them, rather than the lack of (a good) one

Why cause yourself difficulty by drifting towards optionality vs. using the ops suggestion and using venv? This topic gets posted to HN far too often - I'm starting to think people are deliberately avoiding venv for some reason, because otherwise it's a perfectly capable system for package management.

Yeah, many people here are suggesting poetry.

First (and last) time I've tried it, it was a complicated mess when compared to

python3 -m venv

Re: One does not simply 'pip install'

#85

Post by unxdfa »

hnfong wrote: post #59
unxdfa wrote: post #21

Earlier quoted context omitted.

This makes me so happy. Back when we had Jenkins slaves, one of our devops guys set a pipeline up that pip installed different versions over the top of system packages causing weird intermittent failures everywhere. Different pipelines would be running in different requirements files. I revoked sudo privs immediately for Jenkins (I didn't add them in the first place) and reprovisioned the whole build cluster resultin…

> I revoked sudo privs immediately for Jenkins (I didn't add them in the first place) If you allowed sudo in your jenkins jobs you're morally barred from blaming python for screwing up the system.

The problem here started right at the hiring manager.

Re: One does not simply 'pip install'

#87

Post by robertlagrant »

mark_l_watson wrote: post #4

While I agree with the author to not do global pip installs for every new project, I also don’t want to see text in every git repo README explaining Python package managers.

This is where npm gets it right. It's so much simpler to have the default install in a local folder, and then have an option to install globally if you like.

Re: One does not simply 'pip install'

#88

Post by tyingq »

scarface74 wrote: post #83
tyingq wrote: post #58

It's also interesting how things like AWS Lambdas, Graviton, etc, are exposing all the shortcomings of the various pip install, venv, poetry, etc, approaches. It's not impossible to figure it out, but you end up spending a lot of time to come up with something that works locally, within containers, inside a CI/CD system, and then deployed out across things like Lambdas, or non x64 machines. Then, after it's all worki…

At least with Lambda it really is easy, just use Serverless Application Model and when you do “sam build” choose “--use-container”. It will look at your CloudFormation template where you are referring to the local directory containing your source code and requirements.txt and download and build in the appropriate Docker container for your language, version and architecture. It works great when you have native depende…

I assume that means container based Lambdas, which would have slower cold start times and maybe some other disadvantages, but yes, it would be simpler.

Re: One does not simply 'pip install'

#89

Post by rgavuliak »

tyingq wrote: post #58

It's also interesting how things like AWS Lambdas, Graviton, etc, are exposing all the shortcomings of the various pip install, venv, poetry, etc, approaches. It's not impossible to figure it out, but you end up spending a lot of time to come up with something that works locally, within containers, inside a CI/CD system, and then deployed out across things like Lambdas, or non x64 machines. Then, after it's all worki…

Lambdas now work with Docker

Re: One does not simply 'pip install'

#90

Post by wheelerof4te »

throwboatyface wrote: post #6
mark_l_watson wrote: post #4

While I agree with the author to not do global pip installs for every new project, I also don’t want to see text in every git repo README explaining Python package managers.

The lack of one true package management approach is a failure of the language. OP is advocating for a saner default like npm, instead of the current venv + pip mess.

How is npm any saner?

Last week I've had one colleague complain about his brokem npm install. He had to manually install each module and it's exact version.

A month before that, we had one broken old nodejs project which couldn't update itself cleanly.

Post reply on HN