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

31–40 of 118 posts

Re: One does not simply 'pip install'

#31

Post by savingsPossible »

synergy20 wrote: post #10

poetry breaks once a while for me, so I am not using it these days. pipenv used to be my first choice but it became inactive, seems it is actively under development again? a few weeks ago there is a recommendation for PDM but I have not really used it. For now I am using the pip+venv approach. By the way, you better do: `python -m pip install` instead of `pip install`, don't remember why anymore but I did read somewh…

I think there is an issue with different versions of python

If there are 2 installed, then "python" can refer to (say) python 3.10 and pip to python 3.9

using python -m makes you pip with 3.10

Re: One does not simply 'pip install'

#32

Post by ilyt »

virtualritz wrote: post #27

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

I outright look for alternatives for something when the search comes with something written in python; the well-accepted strategy for deploying Python seems to be "abandon all hope of deploying it yourself in a way where updating is easy and hope docker container someone did that dealt with this mess will be enough.

Re: One does not simply 'pip install'

#33

Post by kgwgk »

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

Re: One does not simply 'pip install'

#34

Post by atemerev »

I use Python for research. If I need some package, I simply want the latest version; pip install is usually fine.

If something depends explicitly on the fixed (old) version, that's when problems happen and I grudgingly remember how to use pyenv. But I like to use the most recent versions and most recent Python, and I like packages that share this bleeding edge approach.

Re: One does not simply 'pip install'

#35

Post by yboris »

I've been a happy user of pipenv for several years (at work, in production) and still recommend it. You lock the versions you want independently of the requirements.txt so you can update just the packages you want without worrying about sub-dependencies. 10/10 recommend.

Re: One does not simply 'pip install'

#36

Post by michaelcampbell »

azornathogron wrote: post #29
michaelcampbell wrote: post #20

Earlier quoted context omitted.

> And then node_modules, which packages should not rely on but do, Isn't the point of node_modules to house ... dependencies? I'm confused as to what you're getting at here.

Various packages rely on node_modules existing as a directory with a particular layout, some rely on being able to write into it. Some of the npm alternatives are built to store and manage dependencies in other ways (e.g., keep packages as zip files or other archives and get node to load direct from the zip), and these other mechanisms do not use a node_modules directory, hence compatibility problems.

> these other mechanisms do not use a node_modules directory,

Once you've landed on a package manager that does use it, wouldn't you continue to use that?

Re: One does not simply 'pip install'

#37

Post by Spivak »

virtualritz wrote: post #27

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

To me there’s no mystery. Just use pip and then when you hit a specific problem see if any existing tools solve it.

The game of, “blank project immediately needs 12 different tools I read about on a blog post” is silly.

Re: One does not simply 'pip install'

#38

Post by ilyt »

galleywest200 wrote: post #9
throwboatyface wrote: post #6

Earlier quoted context omitted.

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.

I like venv/pip. I can blow out the directory when I am done with it. I do not need to remember what is installed were. Compare this to my GOPATH/GOROOT which is insanely full of mods...gigabytes...

I'd gladly take $1 worth of storage over venv/pip mess.

> Compare this to my GOPATH/GOROOT which is insanely full of mods...gigabytes...

Go apps are self-contained blobs. You can just... not install it ? `go build` will just leave you with binary blob in root dir you can put whenever.

Re: One does not simply 'pip install'

#39

Post by ziml77 »

lazka wrote: post #11

The next Debian/Ubuntu releases will no longer allow `pip install` outside of a venv: https://discuss.python.org/t/pep-668-marking-python-base-env... You can still force it via `pip install --break-system-packages ...` if needed.

Mixing pip with another package manager has always seemed weird to me. You're just asking for things to conflict and break.

I noticed with Homebrew that there was no way to untangle packages installed through pip and ones installed through Homebrew. After dealing with that mess once, I now make sure to use pip install --user. It can still cause things to break, but if that does happen it's at least easy to nuke the packages installed to my home directory.

Re: One does not simply 'pip install'

#40

Post by forgotpwd16 »

meitham wrote: post #28
lazka wrote: post #11

The next Debian/Ubuntu releases will no longer allow `pip install` outside of a venv: https://discuss.python.org/t/pep-668-marking-python-base-env... You can still force it via `pip install --break-system-packages ...` if needed.

Hopefully that’s not going to be the case inside a container!

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