Thank you! We're excited about it. LSP opens the door for us to gradually provide marimo features in whatever form makes sense for a particular env, allowing more folks collaborate on notebooks.
Unit tests to assert a spec are great, but they don't provide any context as to why the spec was defined as it was. This context is critical when making changes to the spec, so unit tests on their own aren't sufficient in my experience.
Perses is an excellent step towards vendor neutrality. We at Dash0 are basing our dashboarding data model entirely on Perses to allow you to bring/take away as much of your configuration as possible.
The team around Perses did a solid job coming up with the data model and making it look very Kubernetes manifest-like. This makes for good consistency, especially when configuring via Kubernetes CRs.
Didn't know about Perses. Looks promising! I've had one foot out the door with Grafana for a couple years -- always felt heavy and not-quite-there (especially the Loki log explorer), and IMHO they made alerts far less usable with the redesign in version 8.
I followed the link in the description and it brought me to the microscope product page. I clicked "price" and it had a page that told me to enter my business email for a quote lol.
Whatever you do, DO NOT enter your email and absolutely do not give them your phone number. Keyence famously will not leave you alone. They’re very aggressive.
How've you found `uv` as a package manager? I've generally been a fan of Astral's tools in the Python ecosystem and I'm considering making the switch from `poetry`.
They need to add a couple minor painful paths that people usually use package managers with (private indexes, binding packages to third party indexes...) but if you don't need fancy corner cases, it's the best thing ever.
Also any machine learning use cases! There’s a big caveat with uv where they merge your Pipfile and pip installations. For example if you do
uv add flask (this is added to pipfile)
but then you need to add PyTorch with custom indexes (because most ML libraries distribute driver specific versions) and you do
uv pip install PyTorch —-index-url
what you end up with is a pipfile.lock that merges the two. uv won’t automatically add your dependency to the Pipfile.
There's an issue about pytorch (I think you might already have seen it since you encountered this). This is still due to lack of support for pinning a package to a third party index (see https://github.com/astral-sh/uv/issues/171).
I am not sure I totally understand what you mean: yes, the lockfile might be messed up, but is the environment working? I'm a bit blessed because I don't have CUDA on my machine so I save myself a lot of hassle.
I think the docs should be more clear that the uv pip command is an escape hatch, and the moment you use it you basically lose the ability to have the Pipfile as a source of truth. Most devs won't be looking too closely at the lockfile unless it's to debug issues, they usually only refer to the Pipfile. It would also be nice to have a pip to uv/rye command converter like those curl command generators.
I wouldn't say it's an escape hatch: pip and poetry/pdm/uv serve different purposes. I am not sure what you refer to with `Pipfile`. As per the "command converter": you mean something like from `uv pip` to `uv add`?
Yes, a command converter as you described (that supports converting all the pip flags and command parameters) would be very useful. At the end of the day, you need a (readable) single source of truth somewhere (i.e. not the lockfile, the lockfile is fine for deployment and operations but not for developers). As a developer, I don't want the `uv pip` commands to mess up my environment, but at the same time, 90% of the Python world assumes dependency management is done with pip, and when I am installing dependencies, I don't really have time to chase down the exact flags that I should be using to add it to the Pipfile and to ensure uv compatibility.
You are correct - I should've been more specific. Binding a package(s) to a third party index is currently unsupported (see issue: https://github.com/astral-sh/uv/issues/171) as it is something that pip itself does not support. PDM/Poetry implemented this on their own - though this it's an important feature and as far as I can tell it's coming.
Agreed, and Apple's differentiator has always been seamless integration. With the iPhone, they own the boundary layer between the physical and digital worlds. It's an obvious place to introduce AI for daily tasks without requiring any behavioral changes from the users.
There's pretty limited passing on the routes judging from the schedule [0]. It looks like there are a couple sections along the corridor where there's an extra rail for passing [1].
At the end of the day, there will always be people making sweeping generalizations counter-positioning themselves against the hype in order to drive engagement.
There are plenty of companies capitalizing on the AI hype cycle which won't manage to build durable businesses, but there are also plenty of use cases where AI is meaningfully accelerating people's workflows.
Situations where it's effort-intensive to create something from scratch but cheap to validate the output of a model and iterate on it until you're happy seem to be the sweet spot right now. Code co-pilots, generative artwork, copywriting, etc. Granted, these are all incremental improvements rather than fundamental evolutions to how we do work thus far, so that aspect seems overblown, but writing it all off as smoke and mirrors is disingenuous.
This is where your comment went off the rails. Is it possible the author simply disagrees with you? Or is the future of AI so clear that the only reason a person could disagree is because they're driving engagement?
