6 ms·

For me, before I even get to packaging, I hit the install/environment issue with python. Python, by default, wants to be installed at a system level and wants l

For me, before I even get to packaging, I hit the install/environment issue with python. Python, by default, wants to be installed at a system level and wants libraries/packages to be at a system level. That shit has to stop. The default needs to be project local installs. Node might have issues but one thing they got right is defaulting to project local installs vs python where you need various incantations to get out of the default "globals" and you need other incantations to switch projects.

ivoflipse 4y ago
Lucky for you, there's a new PEP proposing just that: https://discuss.python.org/t/pep-704-require-virtual-environments-by-default-for-package-installers/22846/61 https://discuss.python.org/t/pep-704-require-virtual-environ... Written by the author of this blog post no less! However, you'll find that as with all packaging discussions there are people opposing it, because their workflow doesn't match yours and they don't want to change how they work. We, as a community, need a way to resolve such stalemates or I fear we won't make much headway
- earthboundkid 4y ago
  We need some person, a nice person, a benevolent person, who could some how tell other people what to do, dictate it if you will, and it would be best if they could keep up this job for the rest of his or her life. We’ll call them, the Friendly Language Uncle.
  - numbsafari 4y ago
    I’d prefer a crazy aunt to a creepy uncle… but maybe let’s leave family out of it altogether.
    - uranusjr 4y ago
      Parent is referring to a long-running (but somewhat obscure at this point unfortunately) joke https://peps.python.org/pep-0401/ https://peps.python.org/pep-0401/
      - numbsafari 4y ago
        I know. I was trying to say "fuck the patriarchy" with a bit more color.
- numbsafari 4y ago
  My solution to this problem has been … to stop using python as a universal tool for all things and instead use other tools purpose built for those purposes. Unfortunately (or not) that basically means no more python. Because it is definitely a “Jack of all trades, master of none”. Focusing on programming languages that just want to be programming languages and not also a system service makes life so much better. You end up using languages that produce self-contained, easily shippable binaries, or languages with easily embeddable runtimes, instead of trying to write code that has to somehow survive in a “diverse ecosystem”, which generally makes it overly bloated and brittle as it grows so many appendages to solve so many orthogonal incompatibilities it comes to resemble enterprise open source…
- Kwpolska 4y ago
  There’s a competing and saner PEP that actually proposes local package directories (which are not venvs): https://discuss.python.org/t/pep-582-python-local-packages-directory/963/292 https://discuss.python.org/t/pep-582-python-local-packages-d...
kevin_thibedeau 4y ago
The Debian dist-packages/site-packages mechanism alleviates a lot of the problems with dependency hell and clobbering from packages needing to be installed. It's a shame it hasn't been embraced by mainline Python. A case of perfect being the enemy of good. Instead we get the chaos of pyproject as the next great thing.
- ivoflipse 4y ago
  Another lucky winner: https://peps.python.org/pep-0668/ https://peps.python.org/pep-0668/ This PEP is meant to ensure you don't clobber your Linux distro's base environment and break key OS applications. Also, this problem doesn't exist on e.g. Windows, where there is no OS installed python to clobber. Other folks have taught themselves to always use virtual environments for this very reason and therefore don't share your problem. Hence, there are tutorials out there that don't talk about your problem and tools exist where the default behavior might be dangerous on your Linux distro.
asix66 4y ago
You can do this now by creating a Python virtual environment[0]. Then you can package your project with a requirements file and some instructions on its use. I use Python VENV often, and it works really well. [0] https://realpython.com/python-virtual-environments-a-primer/ https://realpython.com/python-virtual-environments-a-primer/
- pronlover723 4y ago
  Apparently you missed the point. local needs to be the default. Not some magic incantation In node cd projectFoo # do stuff, node uses packages local to projectFoo cd ../projectBar # do stuff, node uses packages local to projectBar There is no "activation", the default is it just works. Installing packages local to the project is also the default.
  - thraxil 4y ago
    Activating virtualenvs isn't necessary. In every python project I work in, I do $ cd projectFoo $ ./ve/bin/python whatever... (more realistically, it's `make whatever` which then builds the virtualenv into `./ve` if needed, pip installs required packages into it, and runs the command). Yes, I agree that it would be nice if the default behaviour of `pip install -r requirements.txt` was to install it in an isolated virtualenv specific to that project, but it's not also not like it's completely impossible magic.
  - jessaustin 4y ago
    This is the important difference. Scripting languages should default to examining the current directory and then its parent directory etc. to find the resources they need. Python doesn't have this default and probably can't change at this point.

ivoflipse 4y ago

Lucky for you, there's a new PEP proposing just that: https://discuss.python.org/t/pep-704-require-virtual-environments-by-default-for-package-installers/22846/61 https://discuss.python.org/t/pep-704-require-virtual-environ... Written by the author of this blog post no less! However, you'll find that as with all packaging discussions there are people opposing it, because their workflow doesn't match yours and they don't want to change how they work. We, as a community, need a way to resolve such stalemates or I fear we won't make much headway

earthboundkid 4y ago
We need some person, a nice person, a benevolent person, who could some how tell other people what to do, dictate it if you will, and it would be best if they could keep up this job for the rest of his or her life. We’ll call them, the Friendly Language Uncle.
- numbsafari 4y ago
  I’d prefer a crazy aunt to a creepy uncle… but maybe let’s leave family out of it altogether.
  - uranusjr 4y ago
    Parent is referring to a long-running (but somewhat obscure at this point unfortunately) joke https://peps.python.org/pep-0401/ https://peps.python.org/pep-0401/
    - numbsafari 4y ago
      I know. I was trying to say "fuck the patriarchy" with a bit more color.
numbsafari 4y ago
My solution to this problem has been … to stop using python as a universal tool for all things and instead use other tools purpose built for those purposes. Unfortunately (or not) that basically means no more python. Because it is definitely a “Jack of all trades, master of none”. Focusing on programming languages that just want to be programming languages and not also a system service makes life so much better. You end up using languages that produce self-contained, easily shippable binaries, or languages with easily embeddable runtimes, instead of trying to write code that has to somehow survive in a “diverse ecosystem”, which generally makes it overly bloated and brittle as it grows so many appendages to solve so many orthogonal incompatibilities it comes to resemble enterprise open source…
Kwpolska 4y ago
There’s a competing and saner PEP that actually proposes local package directories (which are not venvs): https://discuss.python.org/t/pep-582-python-local-packages-directory/963/292 https://discuss.python.org/t/pep-582-python-local-packages-d...

kevin_thibedeau 4y ago

The Debian dist-packages/site-packages mechanism alleviates a lot of the problems with dependency hell and clobbering from packages needing to be installed. It's a shame it hasn't been embraced by mainline Python. A case of perfect being the enemy of good. Instead we get the chaos of pyproject as the next great thing.

ivoflipse 4y ago
Another lucky winner: https://peps.python.org/pep-0668/ https://peps.python.org/pep-0668/ This PEP is meant to ensure you don't clobber your Linux distro's base environment and break key OS applications. Also, this problem doesn't exist on e.g. Windows, where there is no OS installed python to clobber. Other folks have taught themselves to always use virtual environments for this very reason and therefore don't share your problem. Hence, there are tutorials out there that don't talk about your problem and tools exist where the default behavior might be dangerous on your Linux distro.

asix66 4y ago

You can do this now by creating a Python virtual environment[0]. Then you can package your project with a requirements file and some instructions on its use. I use Python VENV often, and it works really well. [0] https://realpython.com/python-virtual-environments-a-primer/ https://realpython.com/python-virtual-environments-a-primer/

pronlover723 4y ago
Apparently you missed the point. local needs to be the default. Not some magic incantation In node cd projectFoo # do stuff, node uses packages local to projectFoo cd ../projectBar # do stuff, node uses packages local to projectBar There is no "activation", the default is it just works. Installing packages local to the project is also the default.
- thraxil 4y ago
  Activating virtualenvs isn't necessary. In every python project I work in, I do $ cd projectFoo $ ./ve/bin/python whatever... (more realistically, it's `make whatever` which then builds the virtualenv into `./ve` if needed, pip installs required packages into it, and runs the command). Yes, I agree that it would be nice if the default behaviour of `pip install -r requirements.txt` was to install it in an isolated virtualenv specific to that project, but it's not also not like it's completely impossible magic.
- jessaustin 4y ago
  This is the important difference. Scripting languages should default to examining the current directory and then its parent directory etc. to find the resources they need. Python doesn't have this default and probably can't change at this point.