[HN Gopher] Uv: Python packaging in Rust
___________________________________________________________________
Uv: Python packaging in Rust
Author : samwho
Score : 316 points
Date : 2024-02-15 19:50 UTC (3 hours ago)
(HTM) web link (astral.sh)
(TXT) w3m dump (astral.sh)
| 0cf8612b2e1e wrote:
| Coupling with Rye is very interesting, as that or the PyBi idea
| seem inevitable to take over. Managing different interpreters is
| just too much effort which each tool is handling differently.
|
| Of course, the PSF will remain silent on the issue and let yet
| another tool exist in the ecosystem. I really do not care who
| wins, but we need a standard to be decided.
| OJFord wrote:
| I hadn't heard of Rye before I don't think, but sounds like a
| strange arrangement to me - basically the same project & idea,
| so the new one to start switched the old one to use it 'under
| the hood', 'took it over', and will replace it 'when the time
| is right'? Why.. any of that, why not just buy it and let it be
| uv instead of starting uv, or just leave it alone?
| the_mitsuhiko wrote:
| I wrote down a small little FAQ at the bottom, hope it
| answers some questions:
| https://lucumr.pocoo.org/2024/2/15/rye-grows-with-uv/
| OJFord wrote:
| That is helpful, and fair enough, thanks!
| theyinwhy wrote:
| Why do people here claim that the PSF has any leverage to stop
| tools being developed?
| ericra wrote:
| While I don't see the immediate need to switch from using pip, I
| am such a fan of ruff that I'm always happy to check out what you
| guys come out with.
|
| Please keep doing what you're doing!
| drcongo wrote:
| I've been dying to see what they came up with next given how in
| love I am with Ruff. In my wildest dreams I didn't expect it to
| be a package resolver. I'm very excited about this.
|
| edit: As a side note, if anyone from Astral happens by, any
| chance of an RSS feed on your blog?
| singhrac wrote:
| I was kind of hoping it was a better type checker, something
| like mypy + pyright. To be fair that's an incredible amount of
| work, so maybe we'll see that later. Still very excited.
| drcongo wrote:
| That was actually my first guess, and while I certainly would
| love to see that, packaging is such a headache for so many
| people that this could be amazing. Even with poetry I still
| occasionally get mysterious errors and wildly wrong resolver
| claims about versions not existing.
| marmaduke wrote:
| For envs which are pets, who cares, but this will be great for
| those cattle situations.
| SushiHippie wrote:
| Isn't this basically what pixi wants to be? Wouldn't it be better
| to work together?
|
| https://github.com/prefix-dev/pixi/
| theLiminator wrote:
| Pixi is even more ambitious but with a different philosophy (I
| think? Specifically thinking about how pixi went with their own
| lock and manifest format as well as first class conda support).
| I'd definitely prefer if they worked together instead or
| instead dedicated their time to type checking python which imo
| there still isn't a great solution for.
| SushiHippie wrote:
| Especially the conda support is IMO a cool thing.
|
| As conda/pip interop is just not great. And even micromamba
| (C++ implementation of conda) is relatively slow to resolve
| compared to pip.
|
| But agreed either work together or create a type checker. I
| use mypy currently but it definitely slows down my editor.
| theLiminator wrote:
| Yeah, pixi has decent mixed support for conda/pypi, it
| currently solves and installs conda (then locks it) and
| then solves and installs pypi. I think it's on their
| roadmap to solve them together, which would be a killer
| feature.
| davidhalter wrote:
| I have been working on a faster type checker for 3.5 years
| now. It's coming, I promise :)
| epage wrote:
| Congrats!
|
| > Similarly, uv does not yet generate a platform-agnostic
| lockfile. This matches pip-tools, but differs from Poetry and
| PDM, making uv a better fit for projects built around the pip and
| pip-tools workflows.
|
| Do you expect to make the higher level workflow independent of
| requirements.txt / support a platform-agnostic lockfile? Being
| attached to Rye makes me think "no".
|
| Without being platform agnostic, to me this is dead-on-arrival
| and unable to meet the "Cargo for Python" aim.
|
| > uv supports alternate resolution strategies. By default, uv
| follows the standard Python dependency resolution strategy of
| preferring the latest compatible version of each package. But by
| passing --resolution=lowest, library authors can test their
| packages against the lowest-compatible version of their
| dependencies. (This is similar to Go's Minimal version
| selection.)
|
| > uv allows for resolutions against arbitrary target Python
| versions. While pip and pip-tools always resolve against the
| currently-installed Python version (generating, e.g., a Python
| 3.12-compatible resolution when running under Python 3.12), uv
| accepts a --python-version parameter, enabling you to generate,
| e.g., Python 3.7-compatible resolutions even when running under
| newer versions.
|
| This is great to see though!
|
| I can understand it being a flag on these lower level, directly
| invoked dependency resolution operations.
|
| While you aren't onto the higher level operations yet, I think
| it'd be useful to see if there is any cross-ecosystem learning we
| can do for my MSRV RFC: https://github.com/rust-
| lang/rfcs/pull/3537
|
| How are you handling pre-releases in you resolution? Unsure how
| much of that is specified in PEPs. Its something that Cargo is
| weak in today but we're slowly improving.
| OJFord wrote:
| That is great. Fuzzing would be cool too - just completely
| randomise the versions within the claimed compatibility
| constraints.
| charliermarsh wrote:
| Thanks Ed! Your work as always is a big source of inspiration.
|
| > Do you expect to make the higher level workflow independent
| of requirements.txt / support a platform-agnostic lockfile?
| Being attached to Rye makes me think "no".
|
| Yes, we absolutely do. We don't do this today, the initial
| scope is intentionally limited. But in the next phase of the
| project, we want to extend to multi-platform and multi-version
| resolution.
|
| > How are you handling pre-releases in you resolution? Unsure
| how much of that is specified in PEPs. Its something that Cargo
| is weak in today but we're slowly improving.
|
| This is something we talked with Jacob about quite a bit. Turns
| out (as you know) it's a very hard problem. For the initial
| release, we added a constraint: our default behavior is that if
| you want to use a pre-release, you _have_ to specify the
| package as a first-party dependency and use a pre-release
| marker in the version specifier. (We also support globally
| enabling and disabling pre-releases.) So, we basically don't
| support "transitive" pre-releases right now -- but we give you
| a dedicated error message if your resolution fails for that
| reason.
| woodruffw wrote:
| > How are you handling pre-releases in you resolution? Unsure
| how much of that is specified in PEPs.
|
| The living version of PEP 440 has a bit on how pre-releases are
| handled[1]. The basic version is that the installer shouldn't
| select them at all, _unless_ the user explicitly indicates that
| they want a pre-release. Once opted into, they 're ordered by
| their phase (alpha, beta, rc) and pre-release increment (e.g.
| `.beta.1 > `.alpha.2`).
|
| [1]:
| https://packaging.python.org/en/latest/specifications/versio...
| techwizrd wrote:
| PyTorch doesn't work well with platform-agnostic lockfiles.
| It's a constant source of issues for me when using Poetry.
| notatallshaw wrote:
| There are a couple of promising tools written in Rust looking to
| replace Pip for most users.
|
| Rip (https://github.com/prefix-dev/rip/issues) which is more of a
| library for other rust tools to be on top of like Pixi (which is
| looking to replace both Pip and Conda).
|
| And now uv, which seems to be looking to replace Pip, Pip-Tools,
| and eventually Poetry and PDM.
|
| A lot of the explosion in tools in the Python world is coming
| from the desire for better workflows. But it has been enabled by
| the fact that build configuration and calling has been
| standardized and tool makers are able to follow standards instead
| of reverse engineering easy install or setup tools.
|
| I know a lot of people are put off by there being so many tools,
| but I think in a few years the dust will settle and there will
| emerge a best practice work flow that most users can follow.
|
| As a primarily Python developer and someone who occasionally
| contributes to Pip to solve complex dependency resolution issues
| it does make me wonder if I should hang my hat on that and learn
| enough rust to contribute to one of these projects eventually.
| ShamelessC wrote:
| My experience with Rust developers who dwell in Python land is
| that they fundamentally disagree with most of the language that
| is Python and think they know better than incumbents what
| belongs and what doesn't.
| drawnwren wrote:
| To be fair, python package management is in such a poor state
| that I would expect any outside opinion to not be worse.
| klardotsh wrote:
| The Rust ecosystem gets so much right that honestly, even as
| a career-long Python developer myself (and Rust for many
| years, but that's less of my point), they honestly probably
| _do_ know how to build a good devxp better than much of the
| Python ecosystem.
|
| Put other ways: the Python ecosystem has had 30+ years to
| figure out how to make packaging not suck. It has continually
| failed - failed less and less over time, sure, but the story
| is still generally speaking a nightmare ("throw it all in an
| OCI container" is an extremely reasonable solution to Python
| packaging, still, in 2024). I welcome advances, especially
| those inspired by tooling from languages that focused
| _heavily_ on developer experience.
| sophacles wrote:
| I have written a couple million lines of python
| professionally. Some of that is still in prod.
|
| The last 5 or so years I've mostly done work in rust... so I
| guess I'm a rust developer now.
|
| Do the last 5 years invalidate my opinions, thoughts, or
| skills w.r.t. python somehow?
| daxfohl wrote:
| I'm surprised anyone who has gone from python to rust still
| finds contributing back to the python ecosystem worthwhile.
| eigenvalue wrote:
| Looks awesome. I find that pip is usually pretty fast for me, and
| when it's not, it is mostly because it has to download so much
| data or wait for native libraries to compile in the background
| (or anything involving cuda which always seems to take forever).
| What really needs some help with speed is conda, which is just so
| absurdly slow for literally anything, even on ridiculously
| powerful machines.
| paulddraper wrote:
| Yeah, I'm curious how much uv is actually faster.
|
| npm -> Yarn was life changing performance-wise.
|
| I wonder what pip -> uv is.
| the_mitsuhiko wrote:
| From my testing in rye it's significantly faster in day to
| day. There are numbers in the blog post obviously but it's
| the feeling you get using it locally that makes it much more
| fun to use.
| laborcontract wrote:
| Bun, ruff/uv, polars.. all have been major qol improvements.
|
| I'm loving the pace of release with this crop of speed
| obsessed projects and I _cannot wait_ for astral to tackle
| typing.
| eigenvalue wrote:
| npm seems to have gotten a lot faster lately. All that
| competition from yarn and now bun seems to have pushed them
| to focus on optimization.
| paulddraper wrote:
| Oh certainly.
|
| Npm has improved greatly.
|
| Npm features follow a two-step process: (1) Get implemented
| in Yarn (2) Get implemented in npm.
| rogue7 wrote:
| For conda there is mamba [0], a drop-in replacement that's
| really fast.
|
| By the way, the creator of mamba started his own company at
| https://prefix.dev/
|
| They want to essentially leverage the conda(-forge)
| infrastructure to build a new cross-platform, cross-language,
| cargo-like package manager: pixi
|
| [0] https://github.com/mamba-org/mamba
| maxnoe wrote:
| Since last year, conda itself is actually using the mamba
| solver:
|
| https://conda.org/blog/2023-11-06-conda-23-10-0-release/
| daniel_grady wrote:
| What are some of the reasons that teams use conda (and related
| tools) today? As a machine learning scientist, I used conda
| exclusively in the mid-2010s because it was the only framework
| that could reliably manage Python libraries like NumPy,
| PyTorch, and so on, that have complex binary dependencies.
| Today, though, pip install works fine for those packages. What
| am I missing?
| Ringz wrote:
| Unfortunately, far too often: tradition.
|
| Using only ,,Pythons native tools" like pip and venv simply
| works nowadays so good that I wonder about the purpose of
| many tools like poetry etc. etc.
| pininja wrote:
| Another reason I used to use conda was for easy native
| Windows installation. GPU accelerated packages like OpenCV
| were especially difficult when I used use it 6 years ago.
| Now there's Linux subsystem.. has pip support dramatically
| improved on Windows?
| nateglims wrote:
| The biggest advantage for poetry I found, working with a
| lot of non-traditional software people, is that it does a
| lot of things by default like pin versions and manage
| virtual envs. Unfortunately, it does complicate some
| things.
| Ringz wrote:
| I can understand that well. A few articles from ByteCode!
| helped me to "follow my intuition" and do as much as
| possible with native Python tools.
|
| https://www.bitecode.dev/p/back-to-basics-with-pip-and-
| venv
|
| https://www.bitecode.dev/p/relieving-your-python-
| packaging-p...
| rengler33 wrote:
| This is great. Just adopted the pip-tools approach on a project
| and that has been great. Excited to give this a try.
| maxvt wrote:
| I'd be curious to see how "packaging for production" is
| addressed. As described, this is a tool for development purposes:
|
| > Think: a single binary that bootstraps your Python installation
| and gives you everything you need to be productive with Python,
| bundling not only pip, pip-tools, and virtualenv, but also pipx,
| tox, poetry, pyenv, ruff, and more.
|
| A lot of that dev tooling is not needed in prod, in fact it is a
| liability (features available for misuse, code/image size, higher
| resource requirements). Would there be a "uv-prod" to only deal
| with the minimum subset of environment setup / container building
| that enables production use? Would uv build packages that are
| runnable in prod but themselves don't contain uv? It'd be
| interesting to hear the plans.
| duped wrote:
| Do you plan to support platform-agnostic lockfiles? From the
| wording it sounds like "yes" but also "this is a feature not a
| bug." Which is it?
|
| Checksum verification and portable lockfiles are kind of table
| stakes for me, which is why I use poetry everywhere possible. I
| can't give up correctness for speed.
|
| sidenote: this would be super useful as a library so I could plug
| it into build systems. Managing python dependencies in standards-
| compliant ways is a pain, so shelling out to tools like poetry
| and pip are used even though it would be nicer to write that code
| eg in Rust and just use the parts you care about.
| captn3m0 wrote:
| So what's the plan for monetization? NPM getting acquired by
| GitHub was an anomaly, and I'm wary of letting VC-backed
| companies becoming ecosystem lynchpins.
| anze3db wrote:
| I hope they answer this ASAP. People in the Python community
| are already concerned that Astral is following the Embrace,
| extend, and extinguish playbook.
| aidos wrote:
| If all they did right now was leave Ruff exactly as it was
| and walk away they would have given the Python community a
| great gift.
|
| Sure, it's rendered a bunch of projects obsolete, but it's
| because it's so much better than the predecessors.
| anze3db wrote:
| If they stop development on Ruff today, Ruff won't be
| useful anymore after a few new Python releases. If the
| maintainers of the tools that Ruff is replacing stop
| maintaining them, the whole Python community will be in a
| really bad place. So, there is reason to be cautious.
| Astral being transparent on how they plan to make money
| would be very helpful.
| aidos wrote:
| I do get the caution, but I think that even in that case
| there's enough momentum behind Ruff for the community to
| fork and carry on.
|
| Obviously it would be pretty crummy to end up in a
| situation like pyright where MS really have leant in to
| their embrace, extend, extinguish strategy.
| the_mitsuhiko wrote:
| > If they stop development on Ruff today, Ruff won't be
| useful anymore after a few new Python releases
|
| That is true for every single development tool in the
| Python space.
| cqqxo4zV46cp wrote:
| "People in the Python community"?
|
| Yeah. Probably precisely the same people that call everything
| EEE.
|
| You'll always find people acting alarmist about anything.
| sophacles wrote:
| It's MIT and Apache dual licensed. If the company fails, you
| fork and move on. If the company never makes a dime, that's OK
| for me: some folks got paid to make open source tooling.
| anze3db wrote:
| What they are doing is already discouraging people from
| contributing to the projects their tools are replacing[0]. If
| they go out of business and stop supporting their tools, it
| might leave the Python community in a bad place.
|
| [0] https://www.youtube.com/watch?v=XzW4-KEB664
| woodruffw wrote:
| I'm not sure this is a reasonable framing: LLVM stole much
| of GCC's thunder by being significantly easier to
| contribute to (and extend externally), but I don't think it
| would be accurate to say that LLVM is "discouraging" people
| from contributing to GCC.
| ForHackernews wrote:
| The slow death of GCC has been unquestionably bad for
| copyleft software.
| woodruffw wrote:
| Why is it LLVM's job to be good for copyleft software?
| ForHackernews wrote:
| It's not. But some suspicion of successor projects is
| probably warranted by the devs and users of existing
| tools.
| anze3db wrote:
| I'm not sure if you can compare a project that came out
| of a university and got adopted by Apple with a project
| developed by a VC backed company with no revenue. I'm
| sure Charlie has the best intentions with both ruff and
| uv, but we have no idea how this is going to play out.
| woodruffw wrote:
| My understanding of Ruff's history is that it predates
| Astral, and was originally a side project by Charlie. I
| have similar reservations about VC funding and
| sustainability, but I don't think Ruff was created as a
| trojan horse or with a secret takeover plan in mind.
|
| I agree that we have no idea how it'll play out. But I've
| seen nothing but good faith from Charlie and others, and
| I see no reason to preemptively condemn their attempt to
| build a business.
| marwis wrote:
| LLVM was at least written in the same language it is
| compiling.
|
| In this case they are replacing Python code with Rust
| which might exclude large part of Python community from
| being able to contribute.
| woodruffw wrote:
| By this token, we should be concerned that CPython is not
| written in Python. But that historically has not posed a
| significant risk to CPython's longevity, nor to the
| ability of motivated contributors to learn the C
| necessary to contribute to it.
|
| (Or another framing: only the tiniest fraction of the
| Python community was contributing to CQA tooling in the
| first place. It's not clear that prioritizing the
| interests of the 99.9% of Python programmers who --
| rightfully! -- will never modify these tools makes
| sense.)
| eviks wrote:
| Wouldn't their failure re-encourage people to contribute?
| alfalfasprout wrote:
| While we don't particularly care about pip lockfiles, etc. as
| we're moving to the conda/mamba ecosystem a faster pip is most
| welcome. We invoke it a lot programmatically and it's very, very
| slow.
| iwebdevfromhome wrote:
| Very nice! Not long ago we got rid of a bunch of tools at work in
| favor of ruff. I'm looking forward to this. Specially when the
| time comes to be able to replace poetry with it, hoping it is a
| good implementation.
| murkt wrote:
| An ability to override dependencies, finally!
| amelius wrote:
| Iirc, some pip packages require compilation which depends on
| entire toolchains with e.g. gcc, g++, and with dependencies like
| gtk, Qt, etc. How do they intend to make that less error prone
| and thus more user-friendly?
| cavallo71 wrote:
| That's exactly what conda/mamba/micromamba is covering: the
| whole toolchain.
| amelius wrote:
| I've used conda/mamba, but often ended up with broken
| installs (random coredumps) that were mysteriously fixed by
| just using pip3 instead.
| ZeroCool2u wrote:
| That's what they attempt to cover, but they're not super
| successful at it.
| ofek wrote:
| Exciting stuff! I view Hatch [1] as becoming the Cargo for Python
| because it's already close and has an existing (and growing) user
| base but I can definitely see depending on this for resolution
| and potentially not even using pip after it becomes more stable.
|
| [1]: https://hatch.pypa.io/latest/
| woodruffw wrote:
| This is very exciting! Congratulations to the Astral team on
| their work here.
|
| I have historically expressed trepidation towards external
| attempts to "fix" Python packaging, largely because each attempt
| has historically accreted another layer of incompatibilities and
| hacks onto the giant pile of hacks that are already needed to
| keep the ecosystem running. As such, it makes me happy to see
| that compatibility is a priority here: the Astral team has gone
| out of their way to emphasize both formal (PEP) and informal (pip
| CLI) compatibility with existing tooling and standards.
|
| (Separately, I share concerns about VC funding and
| sustainability. But everything I've seen so far indicates that
| Charlie and the other folks at Astral are not in it to screw or
| otherwise leverage the Python community. So I choose to be
| optimistic here.)
| eviks wrote:
| Prioritizing compatibility with a giant incompatible pile of
| historical hacks is how you grow the pile
| woodruffw wrote:
| I don't think that's true, at least in the case of Python
| packaging. The pile has historically grown because of
| informal or non-existent standards, along with multiple
| independent implementations attempting to align their
| observed (but not specified) behaviors.
| fwip wrote:
| Well, they do explicitly list certain historical features
| that they don't intend to support, like installation from
| eggs or editable installs. So they're doing some work to trim
| the pile while they're there.
| SonOfLilit wrote:
| They do support editable installs, but only from local
| directories. So you have to perform git clone yourself and
| then install.
| SamEdwardes wrote:
| Sign me up! A single binary to manage Python is something I have
| been hoping for.
| chrisshroba wrote:
| Obligatory two xkcd's, but I'm super excited about this project!
| Definitely going to try it out.
|
| https://xkcd.com/1987/ https://xkcd.com/927/
| nindalf wrote:
| Feel like I called this 11 days ago -
| https://news.ycombinator.com/item?id=39251014
|
| > I had to guess, that's the path that the Astral team would take
| as well - expand ruff's capabilities so it can do everything a
| Python developer needs. So the vision that Armin is describing
| here might be achieved by ruff eventually. They'd have an
| advantage that they're not a single person maintenance team, but
| the disadvantage of needing to show a return to their investors.
| 12_throw_away wrote:
| This article says they don't support "platform-agnostic
| lockfiles" YET. And platform-agnostic lockfiles have been
| mentioned in several comments here, times too. I haven't
| encountered these before (with python, anyway) - how do they work
| platform-specific dependencies, e.g., binary wheels?
|
| For instance, there are >30 dists for numpy 1.26.4 [1], with
| different artifacts for different platforms and python
| interpreters. Which of those hashes ends up in a platform-
| agnostic lockfile? Do you have to stick with sdists only?
|
| [1] https://pypi.org/project/numpy/#files
| orf wrote:
| All of them - poetry adds them as an array, and the right one
| is installed for the platform.
| jvolkman wrote:
| PDM and Poetry would include hashes for all possible wheels,
| and would also follow transitive paths for platforms other than
| the current host. E.g. if my host is Linux and I depend on foo,
| and foo depends on bar only on windows, and bar depends on baz,
| my lock file will still contain baz.
| gary_0 wrote:
| Something I've been waiting to see from language package managers
| is more attention paid to security. I believe both cargo and pip
| packages can run arbitrary code as the local user the instant
| they are installed, and malicious packages have existed in the
| wild for years. I also recall a blog post where someone was
| scanning PyPI for malicious Python packages, only to realize that
| `pip download` also executed code.
|
| Just downloading a library to a local source code directory
| should not cause arbitrary code to run on your system, and there
| should be safeguards in place so developers are not one typo away
| from a malicious package pwning their entire system. Supply chain
| attacks remain a huge area of concern.
|
| Instead, when I "ctrl+f security" the homepages of any of these
| new packaging systems, I get 0 results. Not good.
| woodruffw wrote:
| > I also recall a blog post where someone was scanning PyPI for
| malicious Python packages, only to realize that `pip download`
| also executed code.
|
| I think you're thinking of this post[1]. The code being
| searched for wasn't malicious, just buggy :-)
|
| [1]: https://moyix.blogspot.com/2022/09/someones-been-messing-
| wit...
| gary_0 wrote:
| Thanks, that's the one! I was actually just trying to find
| it.
|
| Heh, I forgot about the anime catgirl part.
| the__alchemist wrote:
| Very cool! Of note, I made something along these lines a few
| years ago, although with a slightly broader scope to also include
| managing and installing python versions. I abandoned it due to
| lack of free time, and edge cases breaking things. The major
| challenge is that Python packages that aren't wheels can do
| surprising things due to setup.py running arbitrary code.
| (https://github.com/David-OConnor/pyflow)
|
| For some more context, at the time, poetry and pipenv were both
| buggy, and had some limitations their teams listed as "wont-fix".
| The sort of thing where you hit a breaking bug immediately on
| certain systems. These have since been fixed.
| singhrac wrote:
| Something that is super super important to me is editable
| installs, and local references to those editable installs. Often
| I have several editable packages set up in a virtualenv which I
| think of as like my "base" virtualenv.
|
| One reason I struggled with Rye earlier is that it kind of felt
| like this wasn't entirely supported, possibly because I couldn't
| parse the information on the workspaces or virtual projects page.
| Maybe someone else figured this out? It does seem common enough
| that I would be surprised if it wasn't supported.
| lijok wrote:
| Gonna put my pessimist hat on and say, great - another python
| package manager. If it was at least a drop-in replacement for
| pip, we could switch to it as we did to ruff just for the speed
| gains.
|
| We need a permanent solve for python package management, governed
| by the python steering council.
| raccoonDivider wrote:
| Isn't it a replacement for pip? I've seen people on Twitter
| saying that they migrated very quickly. TFA:
|
| > TL;DR: uv is an extremely fast Python package installer and
| resolver, written in Rust, and designed as a drop-in
| replacement for pip and pip-tools workflows.
| lijok wrote:
| I tested it on my repo, multiple errors, it's not a drop-in
| replacement. (.venv) lijok@mbp icebreaker %
| python -m uv pip install --upgrade uv setuptools wheel
| error: unexpected argument '--upgrade' found tip:
| to pass '--upgrade' as a value, use '-- --upgrade'
| Usage: uv pip install [OPTIONS] <PACKAGE|--requirement
| <REQUIREMENT>|--editable <EDITABLE>> For more
| information, try '--help'. (.venv) lijok@mbp
| icebreaker % python -m uv pip install -- --upgrade uv
| setuptools wheel error: Failed to parse
| `--upgrade` Caused by: Expected package name starting
| with an alphanumeric character, found '-' --upgrade
| ^
|
| I'm sure it can be made to work - but it's definitely not
| drop in
| keb_ wrote:
| Literally the first words in the article says that it's a drop-
| in replacement for pip.
| lijok wrote:
| And you just took a VC-backed company at its word on a
| marketing article? I'm sure that's what they're aiming for,
| but at this time, it's not
| joshSzep wrote:
| And the following examples show it is not. While it is pretty
| straightforward to add `uv ` in front of any pip calls, it is
| not API compatible.
| romantomjak wrote:
| Granted they are still working on it, but in the meantime -
| add a shell alias for uv?
|
| alias pip="/usr/bin/uv pip"
| throw12344612 wrote:
| The PSF has been asleep at the wheel for the past 10-15 years.
| The python packaging ecosystem has only gotten more fragmented
| under their stewardship.
| lijok wrote:
| Fully agree - they need to get it together
| kzrdude wrote:
| A lot is happening these last few years, it's literally
| exploding. I think it will start to consolidate.
| hprotagonist wrote:
| A VC-backed pip-and-more doesn't make sense to me. It's 2024:
| what's the revenue model when the free money printer's on the
| fritz?
| dj_gitmo wrote:
| That was one of my first questions, but Anaconda exists
| https://www.anaconda.com/download/
|
| Python is used by loads of scientists, academics, and other non
| software engineers. Those people need an easy way to use
| python.
| nateglims wrote:
| I knew they sold something, but I am amazed to learn they
| have 300 employees.
| BiteCode_dev wrote:
| Anaconda is very big in corporate envs.
|
| If you want to have a platform that allow to manage Python
| on all machines, including allowed packages and version,
| integrated with ldap, with auditing capabilities, they are
| pretty much the only game in town.
|
| And big companies want that.
| pininja wrote:
| NPM comes to mind. I'm imagining private package management and
| team support https://www.npmjs.com/products
| Kwpolska wrote:
| NPM's got Microsoft/GitHub behind it. I doubt those features
| bring in any serious money, given the abundance of free
| alternatives.
| LtWorf wrote:
| I'm curious to see what the pydantic start up will do.
| ZeroCool2u wrote:
| So uv uses pubgrub-rs, a rust implementation of the pubgrub
| version solving algorithm originally written for the dart
| language. I suppose I shouldn't be surprised, but I always loved
| Pub the Dart/Flutter packaging tool. It's the only thing out
| there that comes close to cargo that I know of. Fun to see these
| chains of inspiration reach across languages.
| endgame wrote:
| How does a language ecosystem that bakes "there should be one--
| and preferably only one --obvious way to do it" into the
| interpreter* as a statement of values end up with such a
| convoluted packaging story?
|
| * Try running `python -c 'import this' | sed -n 15p`
| marclave wrote:
| > Like pip-compile, uv generates a platform-specific
| requirements.txt file (unlike, e.g., poetry and pdm, which
| generate platform-agnostic poetry.lock and pdm.lock files). As
| such, uv's requirements.txt files may not be portable across
| platforms and Python versions.
|
| really curious on the reasoning behind this decision :)
___________________________________________________________________
(page generated 2024-02-15 23:00 UTC)