UV has a killer feature you should know about

1. uv

   1 64 38,547 10.0 Rust

   An extremely fast Python package and project manager, written in Rust.

   

   https://github.com/astral-sh/python-build-standalone is by the same people as uv, so it's hardly random. The releases there include ones with profile-guided optimisation and link time optimisation [1], which are used by default for some platforms and Python versions (and work seems underway to make them usable for all [2]). I don't see any recommendation against using their binaries or mention of optimising for portability at the cost of performance on the page you link or the pages linked from it that I've looked at.

   [1] https://github.com/astral-sh/uv/blob/main/crates/uv-python/d... (search for pgo)

   [2] https://github.com/astral-sh/uv/issues/8015

2. Nutrient

   nutrient.io featured

   Nutrient - The #1 PDF SDK Library. Bad PDFs = bad UX. Slow load times, broken annotations, clunky UX frustrates users. Nutrient’s PDF SDKs gives seamless document experiences, fast rendering, annotations, real-time collaboration, 100+ features. Used by 10K+ devs, serving ~half a billion users worldwide. Explore the SDK for free.

   

3. httpie

   2 130 34,679 6.6 Python

   🥧 HTTPie CLI — modern, user-friendly command-line HTTP client for the API era. JSON support, colors, sessions, downloads, plugins & more. (by httpie)

   

4. homebrew-core

   3 137 13,972 10.0 Ruby

   🍻 Default formulae for the missing package manager for macOS (or Linux)

   

   Yes, I am aware of all of those, although I couldn't offhand tell anyone the difference in tradeoffs between them. But I consider having to install a fresh copy of the whole distribution a grave antipattern. I'm aware that nvm and pyenv default to it and I don't like that

   I did notice how Homebrew sets env GEM_HOME=/libexec GEM_PATH=/libexec (e.g. <https://github.com/Homebrew/homebrew-core/blob/9f056db169d5f...>) but, similar to my node experience, since I am a ruby outsider I don't totally grok what isolation that provides

5. opentofu

   4 77 24,247 9.7 Go

   OpenTofu lets you declaratively manage your cloud infrastructure.

   

   I swear I'm not trolling: what do you not like about modern golang's dep management (e.g. go.mod and go.sum)?

   I agree that the old days of "there are 15 dep managers, good luck" was high chaos. And those who do cutesy shit like using "replace" in their go.mod[1] is sus but as far as dx $(go get) that caches by default in $XDG_CACHE_DIR and uses $GOPROXY I think is great

   1: https://github.com/opentofu/opentofu/blob/v1.9.0/go.mod#L271

6. pip

   5 116 9,631 9.7 Python

   The Python package installer

   

   I don't think so, though maybe I didn't explain myself correctly. You can link to a relative package wheel I think, but not to a package repo.

   https://github.com/pypa/pip/issues/6658

7. juv

   6 1 174 9.2 Python

   Reproducible Jupyter notebooks, powered by uv.

   

8. hcl

   7 47 5,363 7.5 Go

   HCL is the HashiCorp configuration language.

   

   hcl is still MPLv2 https://github.com/hashicorp/hcl/blob/v2.23.0/LICENSE and my complaint is that the .go file has one import path but the compiler is going to secretly use a fork, versus updating the import path like a sane person. The only way anyone would know to check for why the complied code behaves differently is to know that trickery was possible

   And that's not even getting into this horseshit: https://github.com/opentofu/hcl/blob/v2.20.1/go.mod#L1 which apparently allows one to declare a repos _import_ path to be different from the url used to fetch it

   I have a similar complaint about how in the world anyone would know how "gopkg.in/yaml.v3" secretly resolved to

9. CodeRabbit

   coderabbit.ai featured

   CodeRabbit: AI Code Reviews for Developers. Revolutionize your code reviews with AI. CodeRabbit offers PR summaries, code walkthroughs, 1-click suggestions, and AST-based analysis. Boost productivity and code quality across all major languages with each PR.

   

10. hcl

    8 1 1 5.5 Go

    HCL is the HashiCorp configuration language. (by opentofu)

    

    hcl is still MPLv2 https://github.com/hashicorp/hcl/blob/v2.23.0/LICENSE and my complaint is that the .go file has one import path but the compiler is going to secretly use a fork, versus updating the import path like a sane person. The only way anyone would know to check for why the complied code behaves differently is to know that trickery was possible

    And that's not even getting into this horseshit: https://github.com/opentofu/hcl/blob/v2.20.1/go.mod#L1 which apparently allows one to declare a repos _import_ path to be different from the url used to fetch it

    I have a similar complaint about how in the world anyone would know how "gopkg.in/yaml.v3" secretly resolved to

11. installer

    9 3 131 7.9 Python

    A low-level library for installing from a Python wheel distribution. (by pypa)

    

12. CPython

    10 1,451 65,193 10.0 Python

    The Python programming language

    

    Just for the record, `venv` has been in since Python 3.3, although it didn't bootstrap Pip into the environment until 3.4 and wasn't the officially blessed way of doing things until 3.5 (which was still over 9 years ago).

    Pip isn't part of the standard library; the standard library `ensurepip` (called from `venv`) includes a vendored wheel for Pip (https://github.com/python/cpython/tree/main/Lib/ensurepip/_b...), and imports Pip from within that wheel to bootstrap it. (Wheels are zip files, and Python natively knows how to import code from a zip file, so this just involves some `sys.path` manipulation. The overall process is a bit complex, but it's all in https://github.com/python/cpython/blob/main/Lib/ensurepip/__... .)

    This is why you get prompted to upgrade Pip all the time in new virtual environments (unless you preempt that with `--upgrade-deps`). The core development team still wants to keep packaging at arms length. This also allows Pip to be developed, released and versioned independently.

13. gemsh

    11 1 2 - Shell

    Gem environment builder

    The mainline ruby doesn't but tools to support virtualenvs are around. They're pretty trivial to write: https://github.com/regularfry/gemsh/blob/master/bin/gemsh

    As long as you're in the ruby-install/chruby ecosystem and managed to avoid the RVM mess then the tooling is so simple that it doesn't really get any attention. I've worked exclusively with virtualenvs in ruby for years.

14. python-build-standalone

    12 14 2,577 9.3 Python

    Produce redistributable builds of Python

    

    https://github.com/astral-sh/python-build-standalone is by the same people as uv, so it's hardly random. The releases there include ones with profile-guided optimisation and link time optimisation [1], which are used by default for some platforms and Python versions (and work seems underway to make them usable for all [2]). I don't see any recommendation against using their binaries or mention of optimising for portability at the cost of performance on the page you link or the pages linked from it that I've looked at.

    [1] https://github.com/astral-sh/uv/blob/main/crates/uv-python/d... (search for pgo)

    [2] https://github.com/astral-sh/uv/issues/8015

15. python-build-standalone

    13 1 2,487 - Python

    Discontinued Produce redistributable builds of Python [Moved to: https://github.com/astral-sh/python-build-standalone] (by indygreg)

    

    This must have moved recently! I looked at this around end of December and it was hosted on https://github.com/indygreg/python-build-standalone/releases which had nothing to do with UV. If you read through the docs now it still references indygreg and still shows this https://github.com/indygreg/python-build-standalone so I guess the move has not completed it, but yes it's a positive change to see UV taking ownership of the builds.

Suggest a related project