3 ms·

I'm fairly ignorant of the python ecosystem beyond extremely casual use for a few scripts, how does it break your system to do this?

sjsdaiuasgdia 3y ago
There's a few ways Python packages can be installed. They can be installed at the system level, making the package available to any Python program on the system. This can get problematic if not all of your Python usage can function with the same versions of all system-installed packages. They can be installed at the user level, sitting in your homedir instead of somewhere under /usr. This gives some isolation from the system defaults, but may just move the problem down a level - you still have the potential for version conflicts. They can also be installed at the virtualenv level, and now the package install is specific to Python programs launched from that virtualenv. Upgrading a package can only break stuff in that virtualenv, it can't spread beyond it. If you mostly use stuff from the standard library and stable packages that don't change their APIs much, you can go a long way without venvs before it actually bites you.
- ramses0 3y ago
  The thing that _really_ irritates me about debian (almost the only thing, actually) is how flipping hard it is to use it as a development environment/system. It's _great_ as a system, but for the love of $DIETY, why isn't there some sort of way to say: `sudo apt install $ALL_THE_COMPILERS@[latest||version]` ...semi-similarly to the "exceptions" made for frequently updated packages like `firefox`, `chromium`, etc... I know of `asdf`, but it seems like a big miss that it's sometimes so hard to use debian "properly" (ie: via `apt ...`) to actually develop. Or similarly, wouldn't it be great if similar to `LSP-language-server-protocol`, there was something like `PSP-package-server-protocol` where `npm`, `go.mod`, `pip`, etc... were all like: "yeah, the debian system packages for python, perl, etc. are great for debian-on-debian", but we should also support pulling an arbitrary project at an arbitrary version and make a best-effort attempt at being able to isolate, share, manage, upgrade packages between them.
  - imp0cat 3y ago
    You're right, it requires a lot of research and reading to it the "right" way. Also, there are multiple correct option, ie. you mention `asdf`, however I'd recommend `volta.sh` instead. From my experience, I'd recommend sticking with debian packages for everything if possible (they may be outdated, but might still work). Altenatively, you can also cheat a bit, use docker to separate your dev environment from your system.
    - bin_bash 3y ago
      Isn’t Volta only for JS? I always recommend rtx.
      - ramses0 3y ago
        (belated), but thanks for the `rtx` recommendation, I checked it out and it seems like "the right thing". Also keep an eye on the `pixi` tool which got some visibility here recently: https://github.com/prefix-dev/pixi https://github.com/prefix-dev/pixi
  - duped 3y ago
    > Or similarly, wouldn't it be great if similar to `LSP-language-server-protocol`, there was something like `PSP-package-server-protocol If system package managers could support the same use cases as packages managers for your favorite languages then the latter wouldn't need to exist. Distribution maintainers have a very different idea of how dependencies should be managed than most developers using those package managers do.
ramses0 3y ago
/usr/bin/debian-configure-thingy.py => import foo_foo_foo sudo pip3 install bar_bar_bar ...depends foo_foo_foo@v4.5.6 ...but debian-configure-thingy.py expects foo_foo_foo@v1.2.3 (or import path conflicts or whatever)

sjsdaiuasgdia 3y ago

There's a few ways Python packages can be installed. They can be installed at the system level, making the package available to any Python program on the system. This can get problematic if not all of your Python usage can function with the same versions of all system-installed packages. They can be installed at the user level, sitting in your homedir instead of somewhere under /usr. This gives some isolation from the system defaults, but may just move the problem down a level - you still have the potential for version conflicts. They can also be installed at the virtualenv level, and now the package install is specific to Python programs launched from that virtualenv. Upgrading a package can only break stuff in that virtualenv, it can't spread beyond it. If you mostly use stuff from the standard library and stable packages that don't change their APIs much, you can go a long way without venvs before it actually bites you.

ramses0 3y ago
The thing that _really_ irritates me about debian (almost the only thing, actually) is how flipping hard it is to use it as a development environment/system. It's _great_ as a system, but for the love of $DIETY, why isn't there some sort of way to say: `sudo apt install $ALL_THE_COMPILERS@[latest||version]` ...semi-similarly to the "exceptions" made for frequently updated packages like `firefox`, `chromium`, etc... I know of `asdf`, but it seems like a big miss that it's sometimes so hard to use debian "properly" (ie: via `apt ...`) to actually develop. Or similarly, wouldn't it be great if similar to `LSP-language-server-protocol`, there was something like `PSP-package-server-protocol` where `npm`, `go.mod`, `pip`, etc... were all like: "yeah, the debian system packages for python, perl, etc. are great for debian-on-debian", but we should also support pulling an arbitrary project at an arbitrary version and make a best-effort attempt at being able to isolate, share, manage, upgrade packages between them.
- imp0cat 3y ago
  You're right, it requires a lot of research and reading to it the "right" way. Also, there are multiple correct option, ie. you mention `asdf`, however I'd recommend `volta.sh` instead. From my experience, I'd recommend sticking with debian packages for everything if possible (they may be outdated, but might still work). Altenatively, you can also cheat a bit, use docker to separate your dev environment from your system.
  - bin_bash 3y ago
    Isn’t Volta only for JS? I always recommend rtx.
    - ramses0 3y ago
      (belated), but thanks for the `rtx` recommendation, I checked it out and it seems like "the right thing". Also keep an eye on the `pixi` tool which got some visibility here recently: https://github.com/prefix-dev/pixi https://github.com/prefix-dev/pixi
- duped 3y ago
  > Or similarly, wouldn't it be great if similar to `LSP-language-server-protocol`, there was something like `PSP-package-server-protocol If system package managers could support the same use cases as packages managers for your favorite languages then the latter wouldn't need to exist. Distribution maintainers have a very different idea of how dependencies should be managed than most developers using those package managers do.

ramses0 3y ago

/usr/bin/debian-configure-thingy.py => import foo_foo_foo sudo pip3 install bar_bar_bar ...depends foo_foo_foo@v4.5.6 ...but debian-configure-thingy.py expects foo_foo_foo@v1.2.3 (or import path conflicts or whatever)