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

Pyenv – lets you easily switch between multiple versions of Python

github.com

Post reply on HN
Print view View original

311–320 of 341 posts

Re: Pyenv – lets you easily switch between multiple versions of Python

#311

Post by camgunz »

latexr wrote: post #284
camgunz wrote: post #278

Earlier quoted context omitted.

Don't use that one

— Doctor, it hurts when I raise may arm. — Then don’t raise your arm. Like I said in the original comment you replied to and are now ignoring: > That’s not a practical solution. Sometimes you don’t have a choice, as demonstrated above. By that logic one could say “don’t change anything about your system and you don’t even need virtual environments”. Which is somewhat true, but also profoundly unhelpful.

No what you're saying is "Doc I want to only live on bread", to which a reasonable response is "it sounds like you're in jail and have bigger problems."

I'm not ignoring you; I just don't think your use case of "I want to capture the Python from Xcode in my dev env so it's resilient to changes and upgrades" is something anyone wants (or should want) to do. Do you really want to ship on that version? Are you asking your users to install Xcode?

> That’s not a practical solution. Sometimes you don’t have a choice, as demonstrated above. By that logic one could say “don’t change anything about your system and you don’t even need virtual environments”. Which is somewhat true, but also profoundly unhelpful.

In other words: when are you forced to use Xcode's Python for development, and why would that be a good idea? I'm earnestly asking; there may be reasons; I'm just not aware of any.

Re: Pyenv – lets you easily switch between multiple versions of Python

#312

Post by latexr »

scaryclam wrote: post #308
latexr wrote: post #225

Earlier quoted context omitted.

> It's python3.11, not python3, and the python3 "executable" is, itself a symlink to the particular binary (in this example python3.11). Not for the example I gave. If you’re seeing Python 3.11, you’re definitely not using the /usr/bin/python3 on macOS with is made available by the Xcode CLI tools. That’s at 3.9.6 even on Sonoma. > as someone else also points out, you don't even have to use the symlinked versions, yo…

Sorry, but yes I am using macOS for work. I use homebrew as xcode is the issue here, not python or macOS. There are solutions to your problem, you just seem resistant to using them.

> There are solutions to your problem, you just seem resistant to using them.

No, it is you who are failing to understand. I’m describing to you a real scenario, but it’s not one that bothers me. I don’t need you to come up with a solution and didn’t ask you for it. You need to understand not everyone has the same requirements and tradeoffs you do.

Re: Pyenv – lets you easily switch between multiple versions of Python

#313

Post by rovr138 »

airstrike wrote: post #200
rovr138 wrote: post #197

Earlier quoted context omitted.

> feel free to have different versions of python installed side-by-side with some "main" version preferably symlinked as `python` and `python3` This is what pyenv does.

by compiling from source? god no. also it's terribly named because it conflates the idea of python environments with python versions just install pre-compiled python from official sources side-by-side. no pyenv needed

But that’s the point of the tool. Let it manage that for you.

Re: Pyenv – lets you easily switch between multiple versions of Python

#314

Post by latexr »

camgunz wrote: post #311
latexr wrote: post #284

Earlier quoted context omitted.

— Doctor, it hurts when I raise may arm. — Then don’t raise your arm. Like I said in the original comment you replied to and are now ignoring: > That’s not a practical solution. Sometimes you don’t have a choice, as demonstrated above. By that logic one could say “don’t change anything about your system and you don’t even need virtual environments”. Which is somewhat true, but also profoundly unhelpful.

No what you're saying is "Doc I want to only live on bread", to which a reasonable response is "it sounds like you're in jail and have bigger problems." I'm not ignoring you; I just don't think your use case of "I want to capture the Python from Xcode in my dev env so it's resilient to changes and upgrades" is something anyone wants (or should want) to do. Do you really want to ship on that version? Are you asking yo…

> I just don't think your use case of "I want to capture the Python from Xcode in my dev env so it's resilient to changes and upgrades" is something anyone wants (or should want) to do.

Then you are wrong. Simple as that. I’m describing a very real scenario.

> Do you really want to ship on that version?

Holy moly, is it really that hard to understand the difference between wanting and having to? For the use case, and older version in a consistent place which is easy to install is the best solution.

> Are you asking your users to install Xcode?

Triggering an Xcode CLI tools installation is simple and done graphically. And it’s one step removed from installing Homebrew or pyenv, which both need them (even for the scripted installation, pyenv requires git).

> In other words: when are you forced to use Xcode's Python for development, and why would that be a good idea?

See, for a moment there you understood it’s about users, not just your own dev environment, but then went back. Unfortunately, after this conversation with you two I no longer have the energy to go through it in detail in an uphill explanation. Another time, maybe.

Re: Pyenv – lets you easily switch between multiple versions of Python

#315

Post by latexr »

scaryclam wrote: post #309
latexr wrote: post #284

Earlier quoted context omitted.

— Doctor, it hurts when I raise may arm. — Then don’t raise your arm. Like I said in the original comment you replied to and are now ignoring: > That’s not a practical solution. Sometimes you don’t have a choice, as demonstrated above. By that logic one could say “don’t change anything about your system and you don’t even need virtual environments”. Which is somewhat true, but also profoundly unhelpful.

This is more like: - Doctor, it hurts when I hit my head on the wall - Then don't hit your head on the wall You have solutions available, use them

Apparently, “sometimes you don’t have a choice” is a foreign language.

— Hey, so you know how we have this requirement, which came about after years of dealing with and understanding a problem and the available solutions?

— Yes, what about it?

— Well, a random commenter on Hacker News who has zero context of the problem has suggested we use a method we already found inadequate for our specific use case.

— Oh wow, in that case let’s replace the whole system right now.

Re: Pyenv – lets you easily switch between multiple versions of Python

#316

Post by bmitc »

SOLAR_FIELDS wrote: post #290
bmitc wrote: post #267

Earlier quoted context omitted.

That's exactly why I don't really on that for Ubuntu though. It's a single point of failure, when I can just use `asdf` to install Python and easily switch between it, automatically if setup correctly on projects.

I use asdf on my local machine, stuff like deadsnakes is for when you need your CI to use VaguelyOldButStillSupported Python version and don’t want to either compile Python from source or host your own binary

My use case is that I'm almost always using the latest Python version, which many Linux distros don't have in their packaging yet, and I'm upgrading code using old versions to the latest. asdf is the best tool for that.

Re: Pyenv – lets you easily switch between multiple versions of Python

#317

Post by maleldil »

claytonjy wrote: post #120
maleldil wrote: post #112

Earlier quoted context omitted.

How are you installing Pytorch with CUDA with Poetry? I stopped using Poetry because it wouldn't automatically get the CUDA version; instead, it would install the CPU version. I migrated to PDM, which does the right thing.

was this before torch 2.0? With the very notable exceptions of a few mispackaged versions, torch now includes all the relevant Nvidia libs, and I haven't seen it grab the CPU version on a GPU box yet, though I'm not sure what it looks for. A notable open issue in poetry is we can't currently specify one dependency on torch, and have it grab CPU version on some systems and GPU on others. Does PDM solve that?

I don't think PDM solves that directly. What I do is have different lock files for different platforms (e.g. Linux/CUDA and macOS/Metal), but pyproject.toml lists only "torch".

Re: Pyenv – lets you easily switch between multiple versions of Python

#318

Post by maleldil »

thangngoc89 wrote: post #129
maleldil wrote: post #112

Earlier quoted context omitted.

How are you installing Pytorch with CUDA with Poetry? I stopped using Poetry because it wouldn't automatically get the CUDA version; instead, it would install the CPU version. I migrated to PDM, which does the right thing.

Before CUDA 12.0 you have to specify a field in pyproject.toml like this [tool.poetry.dependencies] python = ">=3.10, However, since CUDA 12.0 and Pytorch 2.1.0, just install like normal poetry add torch torchvision

I stand corrected. I was familiar with the first option, which coupled the dependencies with the platform, whereas I wanted a CUDA version on Linux and a Metal version on macOS.

However, this works perfectly with Poetry 1.8 and Pytorch 2.2. I suppose the only problem is what PDM also does, where the lock file is platform-dependent. I'm not sure whether Poetry allows you to select a specific lock file, however.

Re: Pyenv – lets you easily switch between multiple versions of Python

#319

Post by camgunz »

latexr wrote: post #314
camgunz wrote: post #311

Earlier quoted context omitted.

No what you're saying is "Doc I want to only live on bread", to which a reasonable response is "it sounds like you're in jail and have bigger problems." I'm not ignoring you; I just don't think your use case of "I want to capture the Python from Xcode in my dev env so it's resilient to changes and upgrades" is something anyone wants (or should want) to do. Do you really want to ship on that version? Are you asking yo…

> I just don't think your use case of "I want to capture the Python from Xcode in my dev env so it's resilient to changes and upgrades" is something anyone wants (or should want) to do. Then you are wrong. Simple as that. I’m describing a very real scenario. > Do you really want to ship on that version? Holy moly, is it really that hard to understand the difference between wanting and having to? For the use case, and…

>> I just don't think your use case of "I want to capture the Python from Xcode in my dev env so it's resilient to changes and upgrades" is something anyone wants (or should want) to do.

> Then you are wrong. Simple as that. I’m describing a very real scenario.

>> Do you really want to ship on that version?

> Holy moly, is it really that hard to understand the difference between wanting and having to? For the use case, and older version in a consistent place which is easy to install is the best solution.

Tone is hard on the internet, but I'm honestly trying to understand your use case. The way I understand it now is "I want to be able to develop Python programs locally using only Xcode's Python." I'm still not sure why you want to (generally when people ship Python programs they bundle a runtime) but let's set that to the side. For this use case, I don't understand why symlinks don't work for you. Xcode installs to versioned folders so you can have multiple Xcode installs side by side, that way new versions won't overwrite things. I'm obviously not an expert here though; am I missing something?

Re: Pyenv – lets you easily switch between multiple versions of Python

#320

Post by rbanffy »

SOLAR_FIELDS wrote: post #291
Hackbraten wrote: post #247

Earlier quoted context omitted.

What makes you think that GP’s comment is talking about older OSes? My understanding of their comment is that they’re talking about getting older Python interpreters to run on more modern OSes, modern enough that they don’t carry the older Python as a system package anymore. Hence, deadsnakes.

This is not about system packages or OSes, this is about your application needing Python 3.9.7 specifically, and locking to that, and 3.9.7 not being available in repositories anymore (3.9.7 is just an example). So normally you would either need to self host 3.9.7 somewhere or compile it from source on every new machine (which is terrible for CI but fine for local dev, a one off in local dev to build a Python version…

> needing Python 3.9.7 specifically

That's indeed extremely specific. I'd imagine this pain could be self-inflicted with C-based extensions that were compiled (and can't be recompiled) with structures that don't exist in other versions.

I don't want to imagine what other eldritch horrors await developers working on this application.

Post reply on HN