331–340 of 341 posts
I use this every day everywhere. Together with pyenv-virtualenv and poetry it dramatically improved my python experience…
if you're using poetry, how does pyenv-virtualenv fit in?
I have to warn again users that think they have found the silver bullet that pyenv comes with a big caveat: it compiles python on your machine. The number of possible modes of failure in this situation is huge. See also: "Why not tell people to "simply" use pyenv, poetry or anaconda" https://www.bitecode.dev/p/why-not-tell-people-to-simply-use I'm not saying pyenv is not a useful tool, but it is not a tool for beginn…
So, what is "the tool for beginners fighting with python packaging problems"? That is, the pattern seems to be that someone mentions a solution, then a zillion responses as to why it sucks. Is there any tool or pair that sucks least for most cases and beginners? I get that every case is different, but perhaps there are some useful starting points?
For your own projects built from scratch (rather than big multi-dep projects off GitHub), there's a smaller learning curve if you go to the vanilla https://www.python.org/downloads/ , install the latest, and use the included pip to install packages. That'll probably get you very far. It's not like the older days when you needed both Py3 and Py2.
For experts working frequently in Python, tools like Pyenv can make more sense.
Earlier quoted context omitted.
Isn't it using the Python version in the formula?
Yes but there are multiple versioned formulae.
Just looking at a random formula, am I correct to understand that this will use python 3.10 and NOT 3.12?[0] I understand ones like this[1] where there's a note about the issue with newer versions.
What I'm trying to understand is if the python version is specified by the formula or it will default to the newest version. If it requires it to be specified in the formula then doesn't this make it contingent on the maintainer upgrading it every python version? I didn't verify [0], but it looks like it should work with later versions of python, and it it is still using 3.10 then isn't that essentially the maintainers "fault?" Because that's my concern. I can't see how something like this stays updated when it requires a maintainer to update. Seems better to have a >=3.10 and then do ==3.10 if only 3.10 works (odd) or >=3.10 [0] https://github.com/Homebrew/homebrew-core/blob/12a0f6bbbeda8...
[1] https://github.com/Homebrew/homebrew-core/blob/12a0f6bbbeda8...
Earlier quoted context omitted.
You can specify different dependencies in pyproject.toml and then use --extra with pip-compile to pull them in. I do this with dev and test sections for example. Constraints seem like they work like you'd expect here. pip-compile also has the -c flag if you want to use that. I guess I don't know what you mean by OS stuff, but maybe this works for that too?
Hmm. So you generate a requirements.txt and a dev-requirements.txt. It sounds like they have overlapping dependencies? I can't get them to be "layered" where the dev-requirements.txt only has the dev dependencies.
Earlier quoted context omitted.
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.
I also imagine the scenario you mentioned causing a lock to a patch version. But I see this as just a normal steady state a lot of orgs drift to if not staying on top of version updates
Earlier quoted context omitted.
I just hit it a few days ago. 3rd party script that I did not write. The dev has lost interest in it 3 years ago. It is written for 2.7.x (and it is a nontrivial amount of code). So my choices are some sort of pyenv thing (or one of them), or fix up the script myself so it runs on 3.12. I lucked out and someone else had already done the second thing. One project I worked on was 2.4.x. If they ever have to update that…
download python 2.7 and run it? no pyenv needed
Tools you can use to make sure the Python program you wrote keeps working: requirements.txt, pip, pipenv, pyenv, virtualenv, pyenv-virtualenv, virtualenvwrapper, pyenv-virtualenvwrapper, venv, pyvenv, conda, miniconda, poetry, docker, nix. Which ones did I miss? Which of them actually ensure your program always works the same as when you first wrote it, without asterisks?
python -m venv myenv . myenv/bin/activate Ensures you have the same python environment. The other part is OS state.
Forget to install virtualenv? Have fun getting rid of packages in your global system.
Sub-dependencies? You'll have to think of a strategy for it. Most people don't and the reproducibility of their project suffers.
Developer vs production dependencies ? You'll have to think of a strategy for it.
And I think I'm forgetting one, but that's already enough.
Earlier quoted context omitted.
> 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 cas…
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.
Earlier quoted context omitted.
But that’s the point of the tool. Let it manage that for you.
right, but now you know even less about your setup when you some roadblock. and compiling python from source is very slow and error prone because it requires a bunch of flags and other libraries to be available. I have no problem compiling stuff from source generally, but python specifically is a major PITA and I already have homebrew to install python (and anything else), which I trust to have more users and better…
This is the same with a binary though. And with homebrew, you can't follow patches or flags used or if they change.
- https://github.com/Homebrew/homebrew-core/blob/c964ad7fa53ad... - https://github.com/Homebrew/homebrew-core/blob/c964ad7fa53ad... - https://github.com/Homebrew/homebrew-core/blob/c964ad7fa53ad...
Not arguing for good or bad, just saying that the problem isn't limited to this.
Earlier quoted context omitted.
Yes but there are multiple versioned formulae.
Thanks for taking the time. Can you help me understand? Because I didn't get this from the devs. Just looking at a random formula, am I correct to understand that this will use python 3.10 and NOT 3.12?[0] I understand ones like this[1] where there's a note about the issue with newer versions. What I'm trying to understand is if the python version is specified by the formula or it will default to the newest version.…
(I am a Homebrew maintainer).