301–310 of 341 posts
Earlier quoted context omitted.
Works fine for me on macOS. I am using venv the same way you do except some global ones for certain tools.
I thought one of the advantages of pyenv was that you switched to also creating virtual envs using pyenv and managed virtual environments with it too. Maybe not.
OP - I'm curious why you've submitted this today, you seem experienced enough to guess this is not the first time you've used it. Has there been a major change or something happened in the community I need to know about? Or are you just spreading the love for a great piece of open source software?
I've used python lightly for a few decades now. I've never got far enough in to figure out how packages work. Once, at least 10 years ago, I briefly tried to use some published packages. I never figure out how to get it to work at all. Other than that, I've limited myself to what's available in the standard library. I've seen a lot of conflicting information about how python packages work, or should work. If there wa…
Earlier quoted context omitted.
Personally I've had problems with poetry managing virtualenvs in the past so I just don't let it touch them any more. Maybe it's better now, but I don't see any reason to risk it, given how often Python seems to like to ruin my day. I also don't like that by default it wants you to use `poetry run` to run things. Sure you can configure it not to, but it still annoys me
One issue I’ve been encountering is that Poetry isn’t aware of pyenv or `.python-version`. So what I do to initially build my venv is: pyenv exec pip install poetry && pyenv exec poetry install This creates the venv against the correct Python version, and I can now do without `pyenv exec` for this repository. And every time that `.python-version` changes (which I at most do a few times per year per project,) I throw…
Python really makes things difficult :D
I thought the recommended approach these days was to use the venv package built in to python3 with `python3 -mvenv ...`
It is, but the problem with `venv` is that it can only use the same version of Python that you're using. E.g. if your Python installation is 3.8, your `venv` will also use 3.8. Pyenv allows you to use whatever version of Python you want.
just install the different python versions by downloading the binaries or through your package manager and run python3. -m venv and the virtual environment will automatically, forever, use that python version when you activate it.
Pls dont. Just install several pythons with different binary names. ex. python3.8, python3.9, python3.11 No need to complicate things. If using Poetry, you can just do `poetry env use python3.8`.
Here's all the project boilerplate you need with pyenv when working on a new project. > $ pyenv install 3.8 > $ pyenv local 3.8 > $ python3 -m venv .venv > $ source .venv/bin/activate and you're done. Not really sure what you might consider difficult about pyenv, but it's just a tool to instigate your python venvs which is a built tool for most modern versions of python.
- compiling from source
- need to install build-essentials on docker images which takes up lot of space and takes a long time
Earlier quoted context omitted.
For a beginner trying to run someone else's Python project, it is free. You run one command and it works. There's tons more complexity under the hood, but you don't have to deal with it. This is why so many Python projects do resort to Docker. And btw, JS doesn't have this problem, they use NPM.
> For a beginner trying to run someone else's Python project, it is free. Its absolutely, by far, the highest friction alternative on Windows for anyone that doesn't use Docker for other purposes.
- Not if you have to deploy the code.
- Not if you have to import the code in your own project.
Basically, not if you want to do anything by running the code. For which I would suggest an installer instead.
pip+venv mostly work fine for me, but there are some libraries like say numpy/scipy that are heavy so I want to share them across projects instead of installing multiple copies. I use pyenv to create a python version separate from the system version and install global dependencies into that. It's been useful for that and is just a nice way to manage multiple versions of python. So pyenv is a great addition to the tra…
My friend, here is what you seek: https://github.com/jazzband/pip-tools
requirements.txt is flat because it's really the output of `pip freeze`. It's supposed to completely and exactly rebuild the environment. Unfortunately it's far too flexible and people abuse it by putting in only direct dependencies etc.
If you're writing packages, you don't need a requirements.txt at all, by the way. Package dependencies (only direct dependencies) live in pyproject.toml with the rest of the package config. requirements.txt (and pip tools) are only for when you want to freeze the whole environment, like for a server deployment.
Earlier quoted context omitted.
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…
> 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…
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.
- 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
Earlier quoted context omitted.
Yep
How exactly? Isn't a requirements.txt file, generated from pip-compile, incapable of specifying OS stuff? It's also my understanding that pip-tools does not let you make layered requirements files with pyproject.toml files, only with .in files
I guess I don't know what you mean by OS stuff, but maybe this works for that too?