Hacker News Reader

Comment by scaryclam | Hacker News Reader

I'm not sure what you might mean by runtime, but a python venv does make sure you're using the same runtime. There are symlinks in the environments bin directory to the specific runtime. If you're plonking a python3.12 binary over the top of the python3.11 one, then yeah, you'll be using a different one, but that'd be an issue nomatter what you're using.

Just don't uninstall your python binaries and you're fine.

If you want to package everything up into am image or a zip, you can do that too if you want, but in my 10+ year career I've not had much of an issue just using boring venvs.

View on HN

> but a python venv does make sure you're using the same runtime.

It does not.

> There are symlinks in the environments bin directory to the specific runtime.

Precisely. They symlink to a path. Which means that if you have a certain version of Python at one location (let’s say /usr/bin/python3) and later update that (let’s say by upgrading macOS and the Xcode developer tools), the same virtual environment will point to a different version of Python.

> Just don't uninstall your python binaries and you're fine.

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.

The point of the question was to reproduce the same thing without asterisks and you’ve introduced a major one and called it a day.

You can use --copies if you don't want symlinks [0].

[0]: https://docs.python.org/3/library/venv.html

Not with the macOS Python from the Xcode developer tools:

> Error: This build of python cannot create venvs without using symlinks

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.

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.

I think people are really looking for some examples of scenarios where this might be a requirement and your time might be better spent providing one vs. fighting with them. Maybe something like an airgapped gov network with very specific approved and audited software?

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?

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.

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

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

> For this use case, I don't understand why symlinks don't work for you.

I never said that. My assertion was that venv does not ensure the same Python runtime.¹ That’s it. I don’t have a problem with that. But I do know of one situation where it could make a difference and “do it another way” is not a reasonable answer.

If we ever meet in person I’ll gladly explain it in detail.

¹ https://news.ycombinator.com/item?id=39814963

The binary installs aren't that generic in the machines I've used (mac and debian based, so covers a fair bit).

It's python3.11, not python3, and the python3 "executable" is, itself a symlink to the particular binary (in this example python3.11). Upgrading just changes the symlink, which wouldn't affect the venv, which isn't using python3, it's using python3.11.

I didn't introduce anything, I explained how the links are to the versioned binaries, which isn't what you're stating is happening.

Edit to add: as someone else also points out, you don't even have to use the symlinked versions, you can use --copies

> 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, you can use --copies

Which, again, doesn’t work for the stated case.

https://news.ycombinator.com/item?id=39818732

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.

This is not the way you're supposed to be using pyenv

You're supposed to install a specific version of python in a specific place, with a specific name. Say, /usr/local/python-3.10.6

Use pyenv to use that python. Control that by creating a `.python-version` file that says 3.10.6

You now have a project that uses 3.10.6. Unless, of course, somebody installs a different version in that path - at which point you've got bigger issues

Using pyenv to use `/usr/bin/python3` and hoping for the best misses the point

> This is not the way you're supposed to be using pyenv

Because that’s not what the conversation is about. It’s about virtual environments.

If you attempt to reproduce a project in a repo that only includes source and requirements.txt you will not have metadata about the version of Python used.

It seems that there is a way to do this in pip but I don’t think it is widely used: https://stackoverflow.com/questions/19559247/requirements-tx...

Reply on news.ycombinator.com