4 ms·

is there a binary only utility like this that does not requires messing up with python?

by pdyc 2y ago

rented_mule 2y ago
If you install https://github.com/astral-sh/uv https://github.com/astral-sh/uv (it's really just two binaries... uv and uvx), then you can run many Python CLIs, and it will manage everything for you. This means resolving and downloading dependencies without touching your system Python. In this case, you'd type `uvx litecli`. If uvx can't find a suitable Python already installed, it will do its best to download a privately managed version. And it's very fast at doing all this.
- synergy20 2y ago
  I assume it works like pipx, caches the download until a new reboot
  - rented_mule 2y ago
    Yes, uvx's behavior is a lot like pipx, but much faster to start up programs (just as uv is much faster than pip), whether cached or not.
    - darkteflon 2y ago
      Huh, I’m a big rye user but had no idea that uvx was a drop-in replacement for pipx. Thanks!
hprotagonist 2y ago
`pipx run litecli`
- dbtablesorrows 2y ago
  What's wrong with pipx install?
  - hprotagonist 2y ago
    nothing!
    - CRConrad 2y ago
      Lots. Perhaps not with pipx itself, but as a symptom of what's wrong with Python (and most software nowadays) there are lots of problems with it: Everything is such huge stacks of stuff built on other stuff built on other stuff built on other stuff... All huge tottering heaps of infrastructure where shit can (and does) go wrong in every layer. It's package managers running in containers calling dynamically-linked libraries running on virtual machines calling package managers running in containers calling dynamically-linked libraries running on virtual machines... With, say, Turbo Pascal you compiled your code into a .COM file, copied it to a floppy, and people ran it. Just your program. On their OS. No heaps of layers of infrastructure and toolchains to get knotted into a tangle of failing interdependencies. How the fuck can it be so impossible to build stuff like that nowadays?!? Not that I'm blaming pipx (whatevertheheck that is; judging from the name seems to be a relative of pip's, which I've heard of) in particular, or even Python itself, more than anything else. Almost everything nowadays seems to be that way. I just wrote all this in the hope that it might explain why a lot of us (like for instance your interlocutor saghm in a sibling thread) are rather reluctant to pick up all the New[1] Shiny stuff. It all seems to so inevitably bring with it rat's nests -- colonies of rat's nests! -- of interdependent cruft tangled up into tight balls of mud and misery. You lose the will to even start trying anything out. ___ [1]: And yeah, OK, calling Python "New" might be problematic... If we'd gotten around to picking it up some fifteen years ago it might still have been. And maybe not accrued as many layers of cruft.
      - dbtablesorrows 2y ago
        > With, say, Turbo Pascal you compiled your code into a .COM file, copied it to a floppy, and people ran it. Just your program. On their OS. No heaps of layers of infrastructure and toolchains to get knotted into a tangle of failing interdependencies. How the fuck can it be so impossible to build stuff like that nowadays?!? Go or Java PicoCLI with graalvm gets you pretty close to this ideal. (Now Desktop GUI is a fallen idea and we are talking about CLIs). Anyway you're blaming the wrong thing. What pipx and venv do in python is fairly simple stuff. It's pretty reliable on standard setups. The problems if any come from C libraries. The NodeJS Electron stack / docker / kubernetes you can feel free to blame.
- saghm 2y ago
  The fact that there are already multiple comments with different tools recommended for how to easily deal with Python packages is a perfect example of why people like the parent commenter don't want to deal with Python in the first place. I'm sure that "just use pipx" works well for you and others, but for those of us who don't know the difference between the half dozen or so different package managers that seem to be mentioned whenever Python comes up, we don't have any clue whether pipx is the "right" choice or if "uv"/"uvx" like the sibling commenter recommends is better. We could spend time researching to figure that out, but that's exactly what we're trying to avoid in the first place!
  - rmbyrro 2y ago
    There's nothing inherently wrong with having options. This is the classic trade-off between convention and configuration. You can prefer a tech stack that values convention over configuration, while others prefer the opposite. This is totally fine.
    - saghm 2y ago
      I don't disagree with your premise, but I'd argue that's not what's happening here. My perception that Python doesn't have half a dozen different tools for making package management better because the community values choice and prefers it to having a default option that does everything they want, it's that the default one isn't good enough for what people seem to want, and the community is trying to make up for that.
      - darkteflon 2y ago
        pyproject.toml + rye/uv is excellent.
      - rmbyrro 2y ago
        If I had to bet, at least half Python projects use the standard packaging. Python applications vary widly. Having a single standard option for packaging that is good enough for all isn't the core language goal.
djbusby 2y ago
I do all my Python stuff in a container. I've found it easier than the N+ other methods. As a bonus when creating the container one can basically just use the tools the project author likes (pip, ,etc) even legacy things from older scripts.

is there a binary only utility like this that does not requires messing up with python?

by pdyc 2y ago

is there a binary only utility like this that does not requires messing up with python?

If you install https://github.com/astral-sh/uv https://github.com/astral-sh/uv (it's really just two binaries... uv and uvx), then you can run many Python CLIs, and it will manage everything for you. This means resolving and downloading dependencies without touching your system Python. In this case, you'd type `uvx litecli`. If uvx can't find a suitable Python already installed, it will do its best to download a privately managed version. And it's very fast at doing all this.

synergy20 2y ago
I assume it works like pipx, caches the download until a new reboot
- rented_mule 2y ago
  Yes, uvx's behavior is a lot like pipx, but much faster to start up programs (just as uv is much faster than pip), whether cached or not.
  - darkteflon 2y ago
    Huh, I’m a big rye user but had no idea that uvx was a drop-in replacement for pipx. Thanks!

hprotagonist 2y ago

`pipx run litecli`

dbtablesorrows 2y ago
What's wrong with pipx install?
- hprotagonist 2y ago
  nothing!
  - CRConrad 2y ago
    Lots. Perhaps not with pipx itself, but as a symptom of what's wrong with Python (and most software nowadays) there are lots of problems with it: Everything is such huge stacks of stuff built on other stuff built on other stuff built on other stuff... All huge tottering heaps of infrastructure where shit can (and does) go wrong in every layer. It's package managers running in containers calling dynamically-linked libraries running on virtual machines calling package managers running in containers calling dynamically-linked libraries running on virtual machines... With, say, Turbo Pascal you compiled your code into a .COM file, copied it to a floppy, and people ran it. Just your program. On their OS. No heaps of layers of infrastructure and toolchains to get knotted into a tangle of failing interdependencies. How the fuck can it be so impossible to build stuff like that nowadays?!? Not that I'm blaming pipx (whatevertheheck that is; judging from the name seems to be a relative of pip's, which I've heard of) in particular, or even Python itself, more than anything else. Almost everything nowadays seems to be that way. I just wrote all this in the hope that it might explain why a lot of us (like for instance your interlocutor saghm in a sibling thread) are rather reluctant to pick up all the New[1] Shiny stuff. It all seems to so inevitably bring with it rat's nests -- colonies of rat's nests! -- of interdependent cruft tangled up into tight balls of mud and misery. You lose the will to even start trying anything out. ___ [1]: And yeah, OK, calling Python "New" might be problematic... If we'd gotten around to picking it up some fifteen years ago it might still have been. And maybe not accrued as many layers of cruft.
    - dbtablesorrows 2y ago
      > With, say, Turbo Pascal you compiled your code into a .COM file, copied it to a floppy, and people ran it. Just your program. On their OS. No heaps of layers of infrastructure and toolchains to get knotted into a tangle of failing interdependencies. How the fuck can it be so impossible to build stuff like that nowadays?!? Go or Java PicoCLI with graalvm gets you pretty close to this ideal. (Now Desktop GUI is a fallen idea and we are talking about CLIs). Anyway you're blaming the wrong thing. What pipx and venv do in python is fairly simple stuff. It's pretty reliable on standard setups. The problems if any come from C libraries. The NodeJS Electron stack / docker / kubernetes you can feel free to blame.
saghm 2y ago
The fact that there are already multiple comments with different tools recommended for how to easily deal with Python packages is a perfect example of why people like the parent commenter don't want to deal with Python in the first place. I'm sure that "just use pipx" works well for you and others, but for those of us who don't know the difference between the half dozen or so different package managers that seem to be mentioned whenever Python comes up, we don't have any clue whether pipx is the "right" choice or if "uv"/"uvx" like the sibling commenter recommends is better. We could spend time researching to figure that out, but that's exactly what we're trying to avoid in the first place!
- rmbyrro 2y ago
  There's nothing inherently wrong with having options. This is the classic trade-off between convention and configuration. You can prefer a tech stack that values convention over configuration, while others prefer the opposite. This is totally fine.
  - saghm 2y ago
    I don't disagree with your premise, but I'd argue that's not what's happening here. My perception that Python doesn't have half a dozen different tools for making package management better because the community values choice and prefers it to having a default option that does everything they want, it's that the default one isn't good enough for what people seem to want, and the community is trying to make up for that.
    - darkteflon 2y ago
      pyproject.toml + rye/uv is excellent.
    - rmbyrro 2y ago
      If I had to bet, at least half Python projects use the standard packaging. Python applications vary widly. Having a single standard option for packaging that is good enough for all isn't the core language goal.

djbusby 2y ago

I do all my Python stuff in a container. I've found it easier than the N+ other methods. As a bonus when creating the container one can basically just use the tools the project author likes (pip, ,etc) even legacy things from older scripts.