Like sentry made a good logging library, then pivoted to an observability service.
And today I use sentry because I have a great history with their product.
It's smart and a positive way to make money.
I dig it.
PS: ruff is not replacing black (although it will probably in the end), but compete with flake8 and pylint.
Serious question, what is the path for a linter? Where else are people paying for linting as a service?
What I would do is build an entire ecosystem of that quality that would include a tool to solve the Python distributions problem.
Either you help with deployment on the server, and you offer hosting.
Or you help with making an installer, and you offer nodes to build installers for multiple OS and upload to multiple app stores, manage updates, cdn, permissions...
You can even start small and just help with a service for cross-compiling C extensions and scale from that.
Or provide machine learning analysis of the quality of your code and make companies pay for it.
Or go full Continuum.
They are good enough that they can pick and choose whatever they want, really.
When you solve pain, people pay. If readthedoc managed to survive by being a static rst site, astral has a shot provided they keep the business side of things in mind as nicely as they build their user stories.
Starting with some nice developer tooling and going from there doesn't seem crazy at all.
After the core-js debacle[0] earlier this year, it was evident that alot of companies actually do not care care about supply-chain security.
Those that do will happily roll their own hosted repositories that provide little to no guarantees.
[0] https://github.com/zloirock/core-js/blob/master/docs/2023-02...
The natural end state is yet another build service.
There's a FOSS SAST product for Python already, though, called Pysa: https://pyre-check.org/docs/pysa-basics/
I've been using https://rome.tools and really love the work they put into it. It's clear they had people working fulltime on it. But now, what? The code is open-source, there are people working on it, but development has mostly dropped off. I guess that's okay? It just adds a lot of doubt into the longevity of the project.
I'd be wary adding these tools into your stack because their progress relies pretty heavily on VC funding and a tight runway to profitability.
I mean, paying people who work on it, for one?
I mean, these are the famous last words of a lot of non-visionaries. I'm not saying that Ruff is some kind of unicorn, but there are a lot of cases where a seemingly small improvement on an existing technology resulted in a very successful enterprise. Docker, for example. There are others that I'm sure people will chime in with.
Having an automated lint run upon opening a PR seems like a minor expense, especially when you can work on other tickets while you wait.
It lets me actually set up another terminal session to run ruff on every file change - where pylint would take seconds, ruff is essentially instant.
Side note: I really hope mypy can get the same treatment; it runs quickly once its cache is established, but it's terribly slow running from scratch.
the opportunity to bring speed and sanity to the whole Python Ecosystem tooling is large (if you dont feel the pain, you don't do enough python) and honestly i cant belive anyone has been (crazy enough) to try this since Anaconda.