@sgillies @jacob … no? Astral is hardly the *second* mover here - cf pipenv, poetry, pdm, etc etc. But, they’re the first one that has been *funded*, which means it’s not “2 folks fixing bugs on weekends”, it’s “a whole team writing code full time with a purpose”. That makes a *big* difference to the rate of progress. *That* is the point.

You can question whether the money poses a strategic risk if/when it goes away; but you can’t argue the money yields *progress*.

@freakboy3742 @sgillies ha yeah it’s more like the 12th mover than the 2nd. I mean, it’s not even the first that’s been funded.

@jacob @freakboy3742 @sgillies the only times I have ever wanted to be wrong about something more badly have been about US federal politics and the pandemic (unfortunately, I was not wrong either of those times)

@glyph @jacob @sgillies Oh - absolutely this. As enthusiastic as I am about the direction uv is going, I *haven't* adopted them anywhere - because I want very much to understand Astral’s intended business model before I hook my wagon to their tools. It's definitely not clear to me how they're going to stay liquid once the VC money runs out. They could get me onboard in a hot second if they published a "This is what we're planning to charge for" blog post.

@glyph @jacob @freakboy3742 @sgillies

Those neon warning lights should have been flashing this whole time anyway, given that the foundational development workflow tools have been almost exclusively relying on people volunteering their time for the last decade or so. If anything, this has been a push toward making the space meaningfully better _now_ and if it results in a multi-stakeholder open source project at the end of this, it's a win-win overall? It's a load-bearing "if" tho.

@glyph @jacob @freakboy3742 @sgillies

Have we forgotten BitKeeper already?

@freakboy3742 @glyph @jacob @sgillies I haven't adopted uv anywhere for similar reasons. 100% agreed on money being the magic, it turns out you can do a whole lot with 8 hours a day.

@freakboy3742 @glyph @jacob @sgillies Honestly I try to be really open about this stuff in my writing, on podcasts, in 1:1 conversations, Q&A at events, etc. I really have nothing to hide here, and people ask me about it all the time, I just probably haven't done enough proactive sharing.

@freakboy3742 @glyph @jacob @sgillies Charlie did explain their strategy in this interview: https://www.bitecode.dev/p/charlie-marsh-on-astral-uv-and-the

Basically, they are going in a similar market than Continuum: selling provisioning and packaging tools B2B.

Given how much I've seen it cost in corporations, and the friction it introduced, they can pull it off.

But even if they can't, their track record demonstrated enough skill and vision to make a pivot.

@bitecode Thanks - I'll give it a listen. Also - worth noting that Continuum changed its name 7 years ago - it's now called Anaconda (they're my employer :-) )

@freakboy3742 @glyph @jacob @sgillies I won't really try to convince anyone of anything, I'll just share my most honest answer on how I think about this stuff right now. I don't want to charge people money to use our tools, and I don't want to create an incentive structure whereby our open source offerings are competing with any commercial offerings (which is what you see with a lost of hosted-open-source-SaaS business models).

@freakboy3742 @glyph @jacob @sgillies What I want to do is build software that vertically integrates with our open source tools, and sell that software to companies that are already using Ruff, uv, etc. Alternatives to things that companies already pay for today.

@freakboy3742 @glyph @jacob @sgillies An example of what this might look like (we may not do this, but it's helpful to have a concrete example of the strategy) would be something like an enterprise-focused private package registry. A lot of big companies use uv. We spend time talking to them. They all spend money on private package registries, and have issues with them. We could build a private registry that integrates well with uv, and sell it to those companies.

@freakboy3742 @glyph @jacob @sgillies I'm hesitant to share specific examples like that, because we may build something totally different! Or decide that the specific idea isn't good! But part of what we want to do is experiment. So while I worry about people anchoring on any specific idea we share, I also sense and understand a desire for those specific ideas / examples :)

@charliermarsh @freakboy3742 @jacob @sgillies I have heard you say as much on podcasts, and this *could* be quite a sustainable path forward, but the specifics of what and how are actually pretty important. you want to go up against Artifactory and friends, but it’s quite possible that in the course of doing so, you discover that users don’t care about Python so much as Docker, and that makes you heavily prioritize a linux-container workflow, which cuts off native app development at the knees

@charliermarsh +1 on this. The experience with private registries is a bit of a misery. I would be intrigued to see Astral build a "Vercel for Python".

@charliermarsh
I love what you're doing with uv - if you could replace devpi with something super simple and very fast, that supports all the relevant peps, you could eat the internal registry market from the bottom up and iterate from there. We would pay for that. You could call it ir - Internal Registry ;)
@freakboy3742 @glyph @jacob @sgillies

@charliermarsh @freakboy3742 @jacob @sgillies this is just a nightmare scenario that I have made up based on a niche edge case I happen to personally care about a lot, not particularly a likely one, but there are a million like it I could throw out. Until the community knows where this is all going, it’s going to be a point of concern. And I realize that trying to find that path really quickly is hard! I do not read any bad faith into what you’re doing.

@glyph asking Charlie to share specific business plans and ideas is super unfair. There’s real advantage to getting to test stuff out and iterate privately; developing a business model in the open is risky as fuck. It’s fine if you want to withhold judgement but I think right now at this early stage you’re being unfair. @charliermarsh @freakboy3742 @sgillies

@glyph would like to get your thoughts on caching proxies & private package hosting one day

@jacob @charliermarsh @freakboy3742 @sgillies later in the thread I did make it explicit that there’s no way to answer these concerns immediately. I will not feel comfortable until the business plan is proven out, that does not mean I expect that it should or even *could* be proven out immediately, and I am sorry if I implied otherwise!

@jacob @charliermarsh @freakboy3742 @sgillies I realize “the specifics are important” could imply the imperative “give me the specifics!” But that’s not what I was trying to say :).

@glyph @jacob @charliermarsh @freakboy3742 @sgillies I have the position that it does not matter and the PSF/core python should act as if astral turns into a burning pile of flames. (Which to be clear, I neither hope nor expects). A lot of open source software was build by failing companies and we still benefit from all the work that went into it.

@glyph yeah you did and I’m sorry for jumping on you before reading the whole thread. I’m just feeling kinda frustrated at the way this conversation is going and I took it out on you. Sorry again. @charliermarsh @freakboy3742 @sgillies

@jacob @charliermarsh @freakboy3742 @sgillies honestly if Charlie said “here is exactly what we will be doing for the next five years, I promise” I might be considerably *more* suspicious, there’s no way that could be committed to publicly right now

@glyph @freakboy3742 @jacob @sgillies Thanks, I genuinely appreciate that you're thinking about this seriously. To some degree what you're describing is just an unavoidable part of trying to build a business -- we might learn something new and our direction could change. It'd be wrong of me to try to convince you that it's impossible. The best I can do is just be honest about how I view the company and what we want to do vs. what we don't.

@glyph @freakboy3742 @jacob @sgillies For example... It's hard for me to imagine a future where we're not extremely focused on Python. It's the community and ecosystem that we know, it's huge and growing, it's where we we're known and where we know users / companies, etc. But again: that's just me being honest about how I view our roadmap / strategy today (and how I describe it to investors too). I think it's the best I can do right now, won't try to convince you of anything more.

@freakboy3742 @glyph @jacob @sgillies But the core of what I want to do is this: build great tools, hopefully people like them, hopefully they grow, hopefully companies adopt them; then sell software to those companies that represents the natural next thing they need when building with Python. Hopefully we can build something better than the alternatives by playing well with our OSS, and hopefully we are the natural choice if they're already using our OSS.

@charliermarsh @freakboy3742 @jacob @sgillies I certainly hope you succeed. I think there are ways that this could go bad, but I don’t think it *needs* to go bad. There are some significant challenges on the way there which need to be addressed as they come, there’s nothing to do or say right now, today, that can fully address those concerns

@charliermarsh Thanks for the response - and totally understand the limitations around sharing specific plans. The general direction definitely sounds promising; but there's a big gap between here and execution :-)

In terms of messaging - I've missed where you've said these things; the one place it isn't laid out (AFAICT) is the Astral blog/website (beyond high level “we believe in fast Python tools" stuff). A "Why should you trust uv/ruff/Astral?” post would go a long way.

@glyph @freakboy3742 @jacob @sgillies Thank you I appreciate this

@charliermarsh @freakboy3742 @jacob @sgillies in a way I feel bad being critical! You and the team are doing great work, I don’t begrudge you for taking money for it, and my concerns are more like “when the investors push Charlie out for poor EBITDA performance in a down market cycle, how is the new management going to be incentivized to maintain things in a way that serves the community’s interest”, which is obviously at least a few years away

@sethmlarson @freakboy3742 @jacob @sgillies kind of a relief to hear that this is a common sentiment, and maybe I will also remain stalwartly anti-uv until a similar milestone

@glyph @sethmlarson @freakboy3742 @jacob @sgillies As much as I hate VC, I find this whole genre of pearl-clutching around uv weird. FOSS projects flame out all the time too. If Frost loses interest, there’s no PDM anymore. Same for Ofek and Hatch(ling).

I fully expect Astral to flame out and us having to fork/take over—it’s the circle of FOSS. To me uv looks like a genius sting to trick VCs into paying to fix packaging. We’ll be better off either way.

@hynek @sethmlarson @freakboy3742 @jacob @sgillies Even in the best case, Rust is more expensive and difficult to maintain, not to mention "non-native" to the average customer here (who presumably knows enough Python to dip into helping out with maintenance if Ofek or Frost wanders off.

@hynek @glyph @sethmlarson @freakboy3742 @jacob @sgillies SAME! Took me five minutes to move to uv in most projects. Will take me 5 minutes to move to vu, pipper, or whatever might be necessary to move to. I don’t think the VC aspect is at all inherently evil but agree the concern of “going all in” which honestly is changing a half dozen lines of your CI/Dockerfile is some big deal.

@hynek @glyph @sethmlarson @freakboy3742 @jacob @sgillies Armin wrote about that here in the footnote: https://lucumr.pocoo.org/2024/8/21/harvest-season/

> However having seen the code and what uv is doing, even in the worst possible future this is a very forkable and maintainable thing. I believe that even in case Astral shuts down or were to do something incredibly dodgy licensing wise, the community would be better off than before uv existed.

He's Rust-fluent though!

@glyph @sethmlarson @freakboy3742 @jacob @sgillies While I'm on board with the "What's the monetisation strategy?" skepticism, I'm also on board with @hynek's point of view here: no matter what happens to the company bootstrapping it, the code is out there now, and we'll collectively figure out a way to pick it up if necessary (FWIW, my bet would be on the problem never coming up due to the VC exit strategy being an eventual sale to an established dev tools player that wants road map influence).

@simon @hynek @glyph @sethmlarson @freakboy3742 @jacob @sgillies Agreed that it seems net positive for Python's tool ecosystem to get a good rejuvenating shot in the arm. Also positively surprised to see the first Python tool exposing a mode that mimics Go's minimum version model (documented at length at https://research.swtch.com/vgo) that I find extremely impressive and next-gen compared to what conda & pip are doing (as someone who tends to lose whole weekends at a time fixing random breakages in 100+ line dep files).

@frank @hynek @glyph @sethmlarson @freakboy3742 @jacob @sgillies the switching cost I worry most about here is documentation and tutorials - if the Python community goes all-in on uv, and uv then fails, that's a metric TON of tutorials, READMEs, YouTube intros etc that would cease to be relevant

@simon @hynek @glyph @sethmlarson @freakboy3742 @jacob @sgillies that’s a good point. The effort to adjust the docs/blog posts/etc is probably larger than that of the actual use. One thing I like about uv is that, if you squint it’s still pip. Won’t matter to the true beginner but 90+% of the time it’s just “put uv in front of whatever you would normally do” which is better than a wildly different interface

@hynek @sethmlarson @freakboy3742 @jacob @sgillies And the difficulty with VC money here is that it can burn out *all* the other projects in the ecosystem simultaneously, creating a risk of monoculture, where previously, I think we can say that "monoculture" was the *least* of Python's packaging concerns.

@glyph @sethmlarson @freakboy3742 @jacob @sgillies Given how much of Python’s ecosystem nowadays depends on Rust, I don’t consider that a valid argument anymore. As Jacob wrote in the initial post, it’s a thing now wherever we like it or not. uv is neither the first nor the last and it shouldn’t be held against it. I’m pretty sure Hatch has a Rust component nowadays too.

@glyph I think the Rust argument is the least convincing. I know every analogy is flawed, but an awful lot of the scientific Python ecosystem depends on C/C++/Cython and I don't think those are "more native" to the average Python developer either.

@glyph @hynek @sethmlarson @freakboy3742 @jacob @sgillies

> Even in the best case, Rust is more expensive and difficult to maintain,

Given someone with similar level of proficiency in both (which is maybe the main/only point you’re arguing), in my (relatively extensive with both) experience Rust will be easier specifically to maintain/grow than Python.

@djc @hynek @sethmlarson @freakboy3742 @jacob @sgillies I have very little practical experience with rust, and generally see it as “C++, but good” so this is counterintuitive! Why do you way so?

@glyph @djc @hynek @sethmlarson @freakboy3742 @jacob @sgillies In general I find (to me unknown) Rust code significantly easier to maintain equivalent Python code for the following reasons: a) standardized tooling for tests/lints/fmt b) generally much higher test coverage c) very strong type system that catches errors early d) less guessing due to immutability everywhere.

@hynek @sethmlarson @freakboy3742 @jacob @sgillies does it? where? as far as I can tell there are no .rs files in https://github.com/pypa/hatch

@hynek @glyph I don't think anyone is objecting to Rust as a reasonable technical choice for this kind of tooling. But we do have to realistic about it shrinking the potential future maintainers pool by a lot which is a downside to weigh against the benefits. And with paid contributors right now is kind of masks the downside in a way that many of us who have been on the receiving end of this cycle before find concerning.

@coderanger @hynek 100%, and I am definitely not complaining when I use a project that's adopted uv and ruff and everything is almost implausibly fast. it's not really a *bottleneck* in my other projects, but I certainly don't mind the focus on performance that comes along with the choice of Rust.

I certainly don't object to Rust *qua* Rust, I depend on mountains of it in Cryptography and I wish I depended on more. but that's a different element of the stack with a very different context.

@coderanger @hynek but to acknowledge the validity of elements of your critique here as well — it's not like everyone with passing familiarity with Python is jumping at the chance to contribute meaningfully to the packaging ecosystem either. The language barrier is one barrier among dozens and it may not even be the most significant one, but it is the newest one.

@glyph @coderanger I don’t think y’all quite grok what uv makes so special due to your seniority. The speed is really cool, but the reason Rust is elemental is that it’s one compiled blob that can be used to bootstrap and maintain a Python development environment. A blob that will never break because someone upgraded Homebrew, ran pip install or any other creative way people found to fuck up their installations. Python has shown to be a terrible tech to maintain Python.

@glyph @coderanger And Ruff is a separate topic entirely to me; a topic that I see a lot more critical. But we’ve been BEGGING corporations to spend money to fix Python packaging and now we’re turning up our noses. I find that highly irritating. We can’t expect this to be fixed by individuals making beer money on GitHub Sponsors.

@glyph @coderanger @hynek The performance is only one of the carrots involved tho. There's also the benefits of being a single executable outside of Python itself, consolidation, good design and probably something else I'm forgetting.

I've argued that what we've needed in Python packaging is agreement on a single tool to just focus on, and if it ends up being because we have one project that wins because it got 100x the resourcing of the other projects... that's fine?