4 ms·

Is there a good explanation as to why python-level tools like nox and poetry seem to avoid integrating with pyenv? Pyenv seems to be the defacto python version

Is there a good explanation as to why python-level tools like nox and poetry seem to avoid integrating with pyenv? Pyenv seems to be the defacto python version manager, and Pipenv seemed to integrate well with it. Why has the python tooling community moved away from it?

nerdponx 4y ago
I don't think it's for any particular reason, other than that nobody has done it yet. I would imagine that the response of most projects would be "PRs accepted", unless they consider it explicitly out of scope. I could see some projects not being interested in automatically installing versions using Pyenv. But I think most projects wouldn't mind the option to defer to Pyenv before searching PATH, or to otherwise configure a custom Python search path that could be derived from Pyenv and/or other sources. Note that Pyenv is itself basically a pile of shell scripts, and it doesn't work on Windows (although there is a Windows port of it). There might also be a general expectation that this functionality is too complicated to support in a way that makes everyone happy, and that users need to figure it out on their own, e.g. using the technique described in the article here. You can also go the other way and use the Pyenv-Virtualenv plugin.
tempest_ 4y ago
Most people using poetry do not care about python versions outside the one they are currently using. It is a concern for library producers but they are definitely the minority.
drewcoo 4y ago
It seems strange to me that a language that proudly proclaims there is one way to do it seems to embrace TIMTOWTDI at the edges. My uninformed guess is that Guido didn't consider how to install anything to be part of the language so it didn't get much scrutiny. https://idioms.thefreedictionary.com/TIMTOWTDI https://idioms.thefreedictionary.com/TIMTOWTDI
- crabbone 4y ago
  Python never followed that or any other absolutist claim. Python is a huge ball of yarn comprised of donations of, perhaps hundreds individual developers w/o strong ties to each other. If you look inside the project, you find plenty of distinct styles and approaches coexisting and overlapping. The moderation is very weak / non-existent. Installation utilities, however, were in Python since very early on. "distutil" dates back to, probably, one of the first public releases. It's since then was always part of the "standard" library, but it's going to be removed in the name of chaos, anarchy and entropy in one of the upcoming releases. There was never any great design in Python in general, or in distutil in particular, but through a series of bad decisions, which were quickly carved in stone, we ended up with the system we have today. Setuptools was a first community project which grew out of recognition of inadequacy of distutil, but, instead of trying to replace it, it was designed to be a drop-in replacement in terms of interface and was made to depend on distutil in order to do anything useful. This result in setuptools being a lot more convoluted and rigid than desired. Few people wanted to participate in this project, and so it was proclaimed dead several times, setuptools2 was supposed to replace it etc... but the decisions carved in stone wouldn't allow anyone to really dislodge it. Gradually setuptools grew more hair, another pair of horns and wings by merging with distribution, easy_install, resouces_pkg and a bunch of other smaller evils, making itself ever more indispensable. Somewhat in parallel to that process, pip was starting to pick up speed. Pip promised a lot, but never delivered on those promises (eg. setuptools was never able to uninstall packages, while pip has "uninstall" command, it's broken by design). And then anyone who made any sense abandoned Python. Python community was left with Python Foundation people or PyPA in this instance, who are not competent to deal with packaging. The entire activity today around packaging in Python may be described as chaos. It's adding random features based on the assumption that existing features work when they don't. Trying to get rid of the only useful tools while replacing them with tools that rely on the tools being replaced etc. It reads like some sort of an absurdist novel if you have to dive deep into it. And yet, it's a technology used by millions, shuffling trillions of goods and services around the world...
  - drewcoo 4y ago
    Are? You? Serious? And are all your up-voters serious, too? Learn your shit, dude! Because right now, your shit owns you. https://peps.python.org/pep-0020/ https://peps.python.org/pep-0020/
deleted 4y ago
[deleted]
jdxcode 4y ago
pyenv is really slow. It'll increase the time it takes to run `python` by a ton. For me it makes `python -V` take ~120ms but without pyenv it only takes ~13ms. I wrote an alternative that has 0 overhead called rtx. https://github.com/jdxcode/rtx https://github.com/jdxcode/rtx
- infamia 4y ago
  This is amazing! Thank you for this wonderful project. It looks like you've taken care many issues I've experienced with asdf (startup performance, shims, bad/confusing commands, etc.). It looks like I might not need to add anything to .*rc files if rtx is in my path? Either way, I can't wait to try it!
  - jdxcode 4y ago
    > I might not need to add anything to .*rc files if rtx is in my path Generally speaking you'll probably want to use `rtx activate` in your shell rc. However you could use the shims instead if you just wanted to add a directory to PATH instead. Of course you'd be getting rid of one of the major selling points of rtx by using shims, but it's so much faster than asdf the shims aren't as bad as they are in asdf.
crabbone 4y ago
There's no reason to use pyenv, pipenv or nox at all, ever. Whether they want to cooperate with each other, or stand together and cry in a corner -- the community shouldn't care. The community should recognize how little value these tools offer (more like negative value, really), and demand from the people responsible for this part of tooling (i.e. PyPA) to get off their rear and make themselves useful, or step down and clear the way for people who know how to do this stuff. The proliferation of useless tools that advertise themselves as solutions to unnecessary problems created by the core of Python development simply shouldn't be happening. If Python community wants to overcome the ridiculous state it's in right now, it needs to concentrate on fixing the problems at their core, not on creating another layer of duct tape around the rotten core.
BiteCode_dev 4y ago
Pyenv compiles python. This excludes it for pretty much every solution by default, as compiling can fail in so many weird ways. Nobody wants to support something that can turn even the simplest ticket into a game of cluedo.

nerdponx 4y ago

I don't think it's for any particular reason, other than that nobody has done it yet. I would imagine that the response of most projects would be "PRs accepted", unless they consider it explicitly out of scope. I could see some projects not being interested in automatically installing versions using Pyenv. But I think most projects wouldn't mind the option to defer to Pyenv before searching PATH, or to otherwise configure a custom Python search path that could be derived from Pyenv and/or other sources. Note that Pyenv is itself basically a pile of shell scripts, and it doesn't work on Windows (although there is a Windows port of it). There might also be a general expectation that this functionality is too complicated to support in a way that makes everyone happy, and that users need to figure it out on their own, e.g. using the technique described in the article here. You can also go the other way and use the Pyenv-Virtualenv plugin.

tempest_ 4y ago

Most people using poetry do not care about python versions outside the one they are currently using. It is a concern for library producers but they are definitely the minority.

drewcoo 4y ago

It seems strange to me that a language that proudly proclaims there is one way to do it seems to embrace TIMTOWTDI at the edges. My uninformed guess is that Guido didn't consider how to install anything to be part of the language so it didn't get much scrutiny. https://idioms.thefreedictionary.com/TIMTOWTDI https://idioms.thefreedictionary.com/TIMTOWTDI

crabbone 4y ago
Python never followed that or any other absolutist claim. Python is a huge ball of yarn comprised of donations of, perhaps hundreds individual developers w/o strong ties to each other. If you look inside the project, you find plenty of distinct styles and approaches coexisting and overlapping. The moderation is very weak / non-existent. Installation utilities, however, were in Python since very early on. "distutil" dates back to, probably, one of the first public releases. It's since then was always part of the "standard" library, but it's going to be removed in the name of chaos, anarchy and entropy in one of the upcoming releases. There was never any great design in Python in general, or in distutil in particular, but through a series of bad decisions, which were quickly carved in stone, we ended up with the system we have today. Setuptools was a first community project which grew out of recognition of inadequacy of distutil, but, instead of trying to replace it, it was designed to be a drop-in replacement in terms of interface and was made to depend on distutil in order to do anything useful. This result in setuptools being a lot more convoluted and rigid than desired. Few people wanted to participate in this project, and so it was proclaimed dead several times, setuptools2 was supposed to replace it etc... but the decisions carved in stone wouldn't allow anyone to really dislodge it. Gradually setuptools grew more hair, another pair of horns and wings by merging with distribution, easy_install, resouces_pkg and a bunch of other smaller evils, making itself ever more indispensable. Somewhat in parallel to that process, pip was starting to pick up speed. Pip promised a lot, but never delivered on those promises (eg. setuptools was never able to uninstall packages, while pip has "uninstall" command, it's broken by design). And then anyone who made any sense abandoned Python. Python community was left with Python Foundation people or PyPA in this instance, who are not competent to deal with packaging. The entire activity today around packaging in Python may be described as chaos. It's adding random features based on the assumption that existing features work when they don't. Trying to get rid of the only useful tools while replacing them with tools that rely on the tools being replaced etc. It reads like some sort of an absurdist novel if you have to dive deep into it. And yet, it's a technology used by millions, shuffling trillions of goods and services around the world...
- drewcoo 4y ago
  Are? You? Serious? And are all your up-voters serious, too? Learn your shit, dude! Because right now, your shit owns you. https://peps.python.org/pep-0020/ https://peps.python.org/pep-0020/

deleted 4y ago

[deleted]

jdxcode 4y ago

pyenv is really slow. It'll increase the time it takes to run `python` by a ton. For me it makes `python -V` take ~120ms but without pyenv it only takes ~13ms. I wrote an alternative that has 0 overhead called rtx. https://github.com/jdxcode/rtx https://github.com/jdxcode/rtx

infamia 4y ago
This is amazing! Thank you for this wonderful project. It looks like you've taken care many issues I've experienced with asdf (startup performance, shims, bad/confusing commands, etc.). It looks like I might not need to add anything to .*rc files if rtx is in my path? Either way, I can't wait to try it!
- jdxcode 4y ago
  > I might not need to add anything to .*rc files if rtx is in my path Generally speaking you'll probably want to use `rtx activate` in your shell rc. However you could use the shims instead if you just wanted to add a directory to PATH instead. Of course you'd be getting rid of one of the major selling points of rtx by using shims, but it's so much faster than asdf the shims aren't as bad as they are in asdf.

crabbone 4y ago

There's no reason to use pyenv, pipenv or nox at all, ever. Whether they want to cooperate with each other, or stand together and cry in a corner -- the community shouldn't care. The community should recognize how little value these tools offer (more like negative value, really), and demand from the people responsible for this part of tooling (i.e. PyPA) to get off their rear and make themselves useful, or step down and clear the way for people who know how to do this stuff. The proliferation of useless tools that advertise themselves as solutions to unnecessary problems created by the core of Python development simply shouldn't be happening. If Python community wants to overcome the ridiculous state it's in right now, it needs to concentrate on fixing the problems at their core, not on creating another layer of duct tape around the rotten core.

BiteCode_dev 4y ago

Pyenv compiles python. This excludes it for pretty much every solution by default, as compiling can fail in so many weird ways. Nobody wants to support something that can turn even the simplest ticket into a game of cluedo.