droelf

Yes, that is built into `setup-pixi` github action, indeed!

For pixi we also created a octoconda & a "github-releases" channel: https://prefix.dev/blog/octoconda-repackage-github-binary-re...

I just packaged it for pg-forge, nice stuff: https://github.com/wolfv/pg-forge

Now you can install it easily with `pixi`.

We're working hard to get ROS out of dependency hell - https://prefix.dev/blog/reproducible-package-management-for-...

Would love to hear your thoughts.

Thank you, this might be a great way to improve the developer experience in the conda/conda-forge ecosystem.

Yeah, boot time, isolation (proper VM vs containers), and ease of use on a larger Hetzner box.

I've been using unikraft (https://unikraft.org/) unikernels for a while and the startup times are quite impressive (easily sub-second for our Rust application).

Cool! Emscripten-forge also recently got a R distribution that runs natively on the browser: https://blog.jupyter.org/r-in-the-browser-announcing-our-web...

Pixi works for this use case: https://pixi.sh/latest/

It gives you cross-platform binary packages, quickly (also written in Rust).

I think for a small configuration TOML might be fine. Where it breaks down in my opinion is in larger configuration files. It just becomes pretty unreadable.

Think about a Github Action being written in TOML ... would probably not look great!

We've been working on Pixi, which uses Conda packages. You can control versions precisely and also easily build your own software into a package to ship it. Would be curious to chat if it could be useful as an alternative to `mise`.

We've been building `pixi` and more specifically "pixi global" as a replacement for homebrew, but based on Conda packages. It creates a single virtual environment per globally installed tool (deduplication works by hard-linking) and then links out the binaries from the isolated environments to a single place.

It's written in Rust and quite fast: https://pixi.sh

You should really try `pixi` and `pixi global` - uses Conda packages but much faster, and great experience for installing packages globally.

https://pixi.sh

I think this is really cool. We're tackling this problem from the other side by building `pixi` (pixi.sh) which bundles project / package management with a task runner so that any CI should be as simple as `pixi run test` and easy to execute locally or in the cloud.

Interesting project. We'd love to work together for better Lua support in Pixi (through the conda-forge ecosystem). We already package lua and a few C extensions. C extensions are the bread and butter for Pixi, so I think it could be a good fit!

- pixi.sh (docs) - lua package on the registry: https://prefix.dev/channels/conda-forge/packages/lua

Join our discord and we can help! There are lots of users that run it with Artifactory :)

Thanks for bringing up conda. We're definitely trying to paint this vision as well with `pixi` (https://pixi.sh) - which is a modern package manager, written in Rust, but using the Conda ecosystem under the hood.

It follows more of a project based approach, comes with lockfiles and a lightweight task system. But we're building it up for much bigger tasks as well (`pixi build` will be a bit like Bazel for cross-platform, cross-language software building tasks).

While I agree that conda has many short-comings, the fundamental packages are alright and there is a huge community keeping the fully open source (conda-forge) distribution running nicely.

We've been working on all the shortcomings in `pixi`: pixi.sh

It's very fast, comes with lockfiles and a project-based approach. Also comes with a `global` mode where you can install tools into sandboxed environments.

Pixi is native on Windows, can install a wide range of dev tools and has task running built into projects (alongside dependency management).

https://pixi.sh/

Cool that this space is getting more attention - I just came from the reproducible builds summit in Hamburg. We're working on similar low level build system tools with rattler-build and pixi. Would love to have a chat and potentially figure out if collaboration is possible.

We're working on rattler-build (https://github.com/prefix-dev/rattler-build/) - which is a build system inspired by Apko / conda-build and uses YAML files to statically define dependencies. It works really well with pixi (our package manager) but also any other conda compatible package managers (mamba, conda).

And it has Windows support, of course. It can also be used to build your own distribution (e.g. here is one for a bunch of Rust utilities: https://github.com/wolfv/rust-forge)

There is also Dora-RS which looks quite interesting - but I agree, improving ROS would be even better!

https://dora-rs.ai/

There are definitely some similarities, but pixi is explicitly not "Python-only". We support many more package ecosystems (thanks to Conda being language agnostic).

This includes, for example, R, C/C++ compilers, Rust, Go ...

I think it's more comparable to Nix or Docker, actually.

That is a valid criticism. Although I personally have seen Spack come up mostly in HPC workloads which is a bit more specialized. There are many disciplines that might not need the "full power" of something like Spack (e.g. source builds) but just need to setup some computational tooling for computational biology research, physics, etc.

Hi everyone, author here. If someone has questions, do let me know! We really care about open science and reproducibilty.

Resolvo (the SAT solver here) has been really good for us. It helped make some conda-forge bots up to 10x faster than the previous C-based solver (libsolv) while being memory safe.

The specific bot tests went from taking 60 minutes to ~6 minutes which is quite remarkable.

Weird that it doesn't go into LFortran more, they even have an excellent online and mindblowing WASM example. https://dev.lfortran.org/

rip isn't really planned as a tool that you would install on your computer. It's a low-level library.

No plans but we would be happy to explore this further if the poetry-devs want to. Maybe they'll join us at PackagingCon next week: https://packaging-con.org/

We'll build some features sooner or later on the repository side that are going to be interesting for enterprise customers.

But we have a strong and true commitment to open source. A non-open-source package manager would definitely not work for our community!