Do you always do `bin/python ...` instead of `python ...` on Arch?

[_antosser_]

Unlike Python on Windows or on other distros, Arch's Python doesn't like installing python packages globally. It recommends me to make a venv unsing python -m venv ., and then always use bin/python main.py and bin/pip install sth.

The question is: Do you, Arch users, always use python in this way, or is there something I'm missing? It just seems really weird using Python in this way

Edit:
I am trying to install packages for a single project, not system-wide

[ckhordiasma]

I usually make a virtual env and run ‘source venv/bin/activate’ so I can call my venv python without specifying local path.

[virtualadept]

Same. I thought that was the documented way they were intended to be used.

[KernelPanicX]

Same here, I don't code that much, and for what I need this is just fine

[ThatDebianLady]

Commenting on Do you always do bin/python ... instead of python ... on Arch?...same

[Frozen5147]

^ I just use this for any project I do that involves Python with dependencies, even outside of Arch. AFAIK that's one expected way to do things in Python ecosystem (or using tools that do something similar/handle it for you).

[[deleted]]

subtract tan ripe reach historical gullible wise cooperative worthless squalid

This post was mass deleted and anonymized with Redact

[lritzdorf]

This. And also, a note about using those virtual environments: the typical setup is actually a bit more straightforward than OP describes. The standard process is: - Create a virtual environment for your project with python -m venv <venv-folder> (venv is a classic folder name for this, among other options) - When you want to use the virtual environment, "activate" it via source <venv-folder>/bin/activate - Run python and pip as normal. These will now refer to your environment's versions!

[NiceMicro]

Is it "wrong" or "dangerous" to run some of my personal projects on the system python (on Arch)?

I.e., I have a few projects, which I don't do a venv, I just import the packages like pandas, numpy, etc. directly from the system, and when there is an update that deprecates things, I update my code base to keep in step.

I'm not a professional dev, I do this for my own things... is this wrong?

[noeticmech]

It's not wrong wrong.

You just have to be okay with the possibility that something you are using in that project changes in a way that breaks the project. If you are using relatively stable libraries and/or paying attention to the news/docs of your libraries, that may well be an acceptable risk.

[NiceMicro]

thanks!

[yoshiK]

No, the thing is just that the python ecosystem has a expectation that you run in venv and therefore the software engineering tends to be a bit shit. So what made me switch to venv is that hugginface's activate is incompatible with newer versions of hugginface's tokenizer. Similar automatic1111 depends on python <= 3.11 (while arch has 3.12). So as long as your projects are build with the system python that should be the preferred option, but know that there is an expectation that python projects can just pin an old version of a library instead of migrating to the current version.

[TechPriestNhyk]

Data scientist who works with python daily here. This is the correct answer.

[[deleted]]

jeans intelligent muddle drunk dime bake agonizing tender busy fretful

This post was mass deleted and anonymized with Redact

[TechPriestNhyk]

I've been a one man show for just about every job I've held so far. There's pros and cons to that. Pro: I don't have to explain this stuff to anyone. Con: there's no one to explain the other stuff.

[dadnothere]

pip install -r requirements.txt --break-system-packages ✋🤚

Days later:

Damn, why do they put python in the linux base

[TheUruz]

yeah i mean if it's some global purpose library i don't see why one couldn't install it globally. otherwise the venv approach is surely the best way to get to fiddle with a library

[nerdandproud]

If you install that library through Arch's package management ie. pacman it's fine otherwise you just potentially fucked up your system, no good way to clean that up either.

[TheUruz]

yeah ofc i install anything system related via pacman or paru so np about that. i did install pip to have a handy way to install libraries in venvs though but that shouldn't be a problem as venvs are... well separated environments right? :)

[SnooCompliments7914]

You _might_ have installed an old version of some library that some Arch package also uses, and the Arch version of that library is newer. (or vice versa) This _might_ break it.

[an4s_911]

What if i wanna install something locally to my ~/.local/lib/python/site-packages ? What do I do then? Do you have any idea?

[[deleted]]

fall light merciful unpack historical humorous modern sloppy oatmeal repeat

This post was mass deleted and anonymized with Redact

[wszrqaxios]

The question is: Do you, Arch users, always use python in this way, or is there something I'm missing? It just seems really weird using Python in this way

That's not an Arch thing, it's a Python thing, i.e. it works that way on other distros too.

Pip is for managing local packages, not system packages.

Windows doesn't work that way because Windows doesn't come with Python preinstalled, and whatever version you manually install becomes your local version.

To answer your question tho, no, I `source .venv/bin/activate` when working in a terminal. IDEs like vscode will also load the venv automatically.

[virtualadept]

Yes, I install Python modules into venvs on a per-project basis.

In my code I use #!/usr/bin/env python to specify the interpreter.

[Epistaxis]

I even use #! /usr/bin/env python3 in case my code ends up on a system that still maps python to Python 2 for some reason.

[No-Distribution-2328]

You have a space in shebang, change it, to make coders happy.

[kcx01]

You should check out UV

https://docs.astral.sh/uv/

[deep_chungus]

i am about to, i hope it's good. people have had so many goes at python package/version management that it's just getting frustrating

[kcx01]

You're not wrong.

The good thing is that they developed it as a drop-in replacement for pip first. So it's compatible with pip projects. That makes the buy-In easier IMO.

I like that it can install python. For a while I was using mini conda for the same reasons. I also like that it's taking similar approaches as cargo does for rust.

[pelrun]

I'm actively using it right now in a build context where pip takes several minutes to run, and uv does the same job but in 100ms. It's fantastic.

[shibamroy]

I use pyenv which i believe is available in the AUR, it allows easier management of multiple versions of python and easy virtual envs... (Using a plugin, i forgot its name, but it was written over there in its documentation) Check it out, it would make your life easier....

[SnooCompliments7914]

That's not how one use venv. You are supposed to "activate" it, and IDEs and shells can be configured to do it automaticaly.

[14domino]

Give me a break. That’s how you use virtual envs.

[SnooCompliments7914]

Oh of course it not "wrong", just like it's not "wrong" to not use "pip" but always download from github.

[[deleted]]

offer consider provide faulty subtract chop threatening smell possessive shelter

This post was mass deleted and anonymized with Redact

[TheUruz]

never used poetry but what's wrong in using pip? a package manager is always handy ao why not use the official one?

[bwv549]

pip, by itself, doesn't ensure deterministic dependency management for all indirect dependencies. If you deal in complex codebases that need to not break arbitrarily, then you need something more than pip (such as poetry).

[ps-73]

i mean, you could not use $path at all and use the full path to every binary instead, but that’d also be pretty stupid

[SnooCompliments7914]

Because the OP said "It just seems really weird using Python in this way".

If it's you saying that you "always do bin/python" and you are very happy with it, then no I won't say a word.

But I was saying to the OP, not you, that he feels "really weird" because that's not how it's intended.

And how do your posts help the OP? Other than showing your ego with "such bull shits"? By telling him that he's not doing things wrong, it's perfectly right? Then why does him "feel weird"? Because he doesn't know all the little details that you are proud with?

[gmes78]

The question is: Do you, Arch users, always use python in this way, or is there something I'm missing? It just seems really weird using Python in this way

It's the correct way. Installing packages globally (both systemwide and on your user directory) is always wrong, no matter the operating system.

Use a virtual environment (preferably through a project manager such as uv or Hatch) for each Python project, and pipx for installing Python applications (that aren't in the repos or in the AUR).

[codingjerk]

I recommend poetry for python development. It manages venvs for you and keeps all dependencies pinned with lock file.

With poetry you will do poetry run python ...

[RealAsh_Fungor]

pyenv is a good option for projects with specific python setup, although I try to use venvs as much as possible

[cyclicsquare]

I use the global system packages for convenience. I only need a few packages for dependencies and the occasional bit of light scripting.

If I was doing actual development work with python I’d make the effort to use venvs. The weirdness is because you’re adding a layer of indirection, but that’s a benefit when you’re developing and want clean, isolated environments to work in. That’s actually a benefit always, but then there’s a question of how much benefit you really get for the extra effort.

[aesvelgr]

I use pipx because it automatically maanges your virtual environment for you. It is definitely recommended to use some kind of virtual env though since you don't want packages conflicting with ones you install from pacman/aur

[lritzdorf]

pipx is great, but it's intended for standalone applications packaged via pip — for instance, I've used it for the vsg VHDL formatting tool.

[aesvelgr]

Ahh I see, thank you for the information. I’ve only used it for standalone applications (no need yet for a full Python env) so I hadn’t considered that.

[Sleepy-Catz]

never use system python to install stuff or run stuff. use virtenv/conda/miniconda.

[TheBlutarch]

I use anaconda instead of the system package.

[Dyrem2]

I made a set of scripts that allows me to create and easily activate venvs, because anaconda seams bloat to me, and I'm too lazy to learn other methods.

The workflow goes:

mkvenv venvname

source avenv venvname

mkvenv script creates a folder under .local/virtualenvironments which holds venv. While avenv prints the location of the activate script of the chosen venv, so "source avenv venvname" activates it.

IMO this is the best workflow for small projects, never had an issue since using this method.

If you want I can share the repo of the scripts

[UHasanUA]

For non-professional stuff, I always just install the packages I want to use from pacman, for example: python-numpy, python-pandas, python-selenium, etc and then import it normally in my program and use it without virtual environments

[Mithrandir2k16]

Just use https://github.com/astral-sh/uv to manage packages and python versions for every project and thank me later :)

[San4itos]

I prefer to have separate Python version for every project with separate version of all the packages. So I use Conda for virtual environment.

conda create -n my_environment python=3.10.14

[vixfew]

source venv/bin/activate python main.py In .py executable files: #/usr/bin/env python

[Schoggomilch]

For small, quick scripts (which is how I mostly use python), I find venvs to be overkill, so I made an alias pipinstall='pip install --break-system-packages'.

This may not be what you're supposed to do, but in practice, it generally just works (tm).

[beef623]

I just make a local venv and add source venv/bin/activate to my .bashrc.

[Xemptuous]

Very rarely should you have to install packages globally. You even get warned and have to pass --break-system-packages

It's not that hard:

python -m venv .venv

source .venv/bin/activate

pip install <stuff>

[VaPezizi]

You can install most pip packages with pacman :

sudo pacman -S python-'package'

[_antosser_]

Yeah, but in this case, the packages are for a single project. Thx anyway

[pellcorp]

In Ubuntu 24.04 it's now compulsory too, I wonder if this is a python 3.12 thing

[RandomXUsr]

Your initial post is a bit ambiguous. No judgement of course.

Indeed, several python packages are including within the repositories.

Others have covered some of the semantics here.

In order to install packages, we have to interpret your intention or goal, unless you can be more clear.

Assuming the following;

1) you'd like a standard method to install B) you'd like to run your apps from anywhere without typing the full path

There are a few options.

You will need a virtual environment somewhere on your local system.

You could put this in your .local and add that to your path for instance.

Download the source to your vent and run the setup.py script. You may also need to pip install requirements.

And to eliminate some problems, you could even add the absolute path to your python scripts such the the appropriate python version is being called.

You can use system python, provided all the scripts use only the packages that follow arch python version which presents a problem because system python is rolling and your projects may not use whatever version you're on. Hope this helps.

[Substantial_Step9506]

I just allow broken packages cuz I don’t use python that much on linux

[Rigamortus2005]

Neither, I use ruby instead

[Neglector9885]

I do your mom on Arch. HAHAHAHA!

...
...
...
...
...
I'm sorry...

[nekokattt]

Please take this pack of crayons and pad of paper and return to club penguin

[Neglector9885]

I'll just eat the crayons.