Live data from Hacker News

One does not simply 'pip install'

ianwootten.co.uk

91–100 of 118 posts

Re: One does not simply 'pip install'

#91
post #74
post #70

This post points out one of my struggles with python. I am not a python developer but I use python heavily for some tooling. So all I need to do is to “distribute” my tools to other servers in a replicable and consistent matter, isolated from global packages. Can you please help me understand two points? 1. If I use venv+pip to install some python app, do I have to “activate” that specific virtual environment before…

1: usually you can just run the binary by its path. tbh I don't fully understand why it doesn't always work, but it's fairly rare, and most of the ones I can kinda-remember may have been during install time. 2: due to 1, symlinks often work. It's how I've installed all of my custom python binaries. Otherwise you'll very frequently see python "binaries" installed by e.g. Homebrew that are actually ~5 lines of minor en…

Thanks! I’ll check out pipx!

Re: One does not simply 'pip install'

#92

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.

As a non-python person who has hair-pulling with python pip / pip3 / python2 / python3 python-is-python2-or-python3, this was a relevation.

pipenv looks like what pip should have been.

Another story on HN is "what happened to Ruby" and that really crystallized what I don't like about python. I'm not a ruby programmer, but I have to admit how much fantastic software came out of Ruby.

Ruby was always fighting Java for some reason, it should have been fighting Python. If only Ruby had won THAT war.

Re: One does not simply 'pip install'

#93
post #76
post #70

This post points out one of my struggles with python. I am not a python developer but I use python heavily for some tooling. So all I need to do is to “distribute” my tools to other servers in a replicable and consistent matter, isolated from global packages. Can you please help me understand two points? 1. If I use venv+pip to install some python app, do I have to “activate” that specific virtual environment before…

1. You can call it directly by referencing the venv python exe eg /pqth/to/your/venv/bin/python /path/to/your/script.py

Nice, I think this is what I was looking for!

Re: One does not simply 'pip install'

#94
I appreciate the concern for new developers, but I really don't think it's a good solution to have every project readme describe pip, poetry, pipenv, and whatever other new hotness there is in the package management world. There's a reason that all the readmes describe pip installation: it's the lowest common denominator, present with every standard python install, and along with virtualenv (also standard) it can do most of the requirements for package management.

I think to help new developers, we could encourage documentation to briefly point to the official PyPA documents on the variety of options available. It would be better to focus on making that more accessible, rather trying to throw the burden onto package maintainers to describe using their package with every new tool.

https://packaging.python.org/en/latest/key_projects/

Re: One does not simply 'pip install'

#95
post #50

> There’s no shortage of package management alternatives available for Python [...] > How someone is meant to pick between these as a new developer is a mystery. This. Every time I get booked to look at some Python project hours are usually wasted initially figuring out what dependency mgmt solution was used how. And with what 'special sauce' the resp. developers deemed to be 'the right way' (or some library required…

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)

I feel mischievous

    python -m venv node_modules

Re: One does not simply 'pip install'

#96
post #53
post #33

> You might expect if I were to pip uninstall requests that I get back to a clean system, right? Why would i expect that? If one day I install A and another day I install B, which depends on A, I wouldn’t expect to lose A of I were to uninstall B.

If I didn't have A installed and then I install B which transitively installs A, then I expect that uninstalling B will also uninstall A. If only one system is managing the packages, then it is able to do this. It will have a record of the things I've explicitly installed so it knows what dependencies are safe to uninstall.

I prefer a package manager that tells me that there are things that may be safe to uninstall to one that decides to uninstall things on its own.

Maybe I installed B who installed A. Maybe sometime later I needed A and I didn’t do anything because it was already there. Seeing A disappear when I uninstall B may be unexpected.

Re: One does not simply 'pip install'

#97

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.

> instead of the current venv + pip mess

It isn't a mess: venv + pip is simple and (usually) sufficient.

Legacy/existing code or genuine justifications excepted, of course, there is no need to use anything else - even if an alternative is better, the use of alternatives is usually worse. Short of any massive technical reason, the best option is almost always to use the default option.

Re: One does not simply 'pip install'

#98

Earlier quoted context omitted.

Why? Can overwrite it and even if couldn't making a new venv is just a `python -m venv venv` away.

Venv in a container is unnecessary ritual. It's a container, it has its own entire root filesystem...

You could have a container whose entry point is a shell script that calls multiple Python programs that need different environments, or a multiprocess container that runs multiple Python programs, although I guess you could still address either by breaking down your containers differently.

Re: One does not simply 'pip install'

#99

npm certainly has a number of problems (at the end the article compares pip to npm) -- but after reading this article I didn't realize pip was so problematic. I also didn't realize it installed things globally. So the solution is?

> I also didn't realize it installed things globally

It doesn't. It's a subtle distinction but the 'blame' doesn't lie with pip. When you do a pip install it does it in the context of the python interpreter you're using.

If you use your global python you get an installation in a global context from pip. If you use a non-global python you get a non-global installation from pip. And this is what venv etc give you; a local interpreter, which means the associated pip installs in a local context (a separate one for each venv).

Re: One does not simply 'pip install'

#100

npm certainly has a number of problems (at the end the article compares pip to npm) -- but after reading this article I didn't realize pip was so problematic. I also didn't realize it installed things globally. So the solution is?

I don't understand why pip doesn't do it like npm. Admittedly, I don't write Python code much, but "npm install xyz@1.2.3" simply installs to a node_modules/ folder in the current directory. Very easy to parse and nuke if I need to. I don't really understand how venv and its weird shell prompt are a better solution.

Yeah. I often nuke the node_modules directory and start again.
Post reply on HN