Concerns about m - nix3 interoperability

[blaggacao]

In our adoption of makes, the principal possibility of running remote scripts with m has caused some confusion, and given the size & diversity of our org, that problem will likely exacerbate. Let me explain:

While makes does a pretty decent job at replicating some functionality of flakes (run from remote & registries), once an org switched to a flakes world and still is primarily anchored in nix, not m, those amenities start to clash in an otherwise peaceful coexistence.

This might lead to the point where some non-fully-briefed devops might start to implement things the m way, where existing APIs / practices already leverage nix run ....

In my opinion, a good way to avoid this incipient vicinity conflict would be if makes, in the presence of nix3 would feature-flag-disable those features. It would also open a good outlook to (further) simplify the implementation of m once nix3 becomes stable.

Another option would be to implement them in a fully compatible manner from the start, so that switching is equivalent of disabling that compat layer.

Equivalences are:

• remote execution -> nix run somerepo#__makes__.attr
  • If need be, we could embellish that interface via a thin wrapper around m to keep up the illusion.
• registry -> nix run --inputs-from (use a custom registry)

[blaggacao]

Btw, I like repo@branch better than repo/branch. Ideally we could place an RFC upstream to also accept this notation.

[kamadorueda]

I'm open to this, just a few things to take into account:

• I'm currently on the priority of migrating all Fluid Attacks from its internal Makes to github:Makes. This in consequence will grow the framework a lot and also reveal improvement points and use cases we have not seen yet, like those we added for kubernetes and aws batch a few days ago. These are killer features for adoption, because they help the community get things done, and also lowers a lot the barrier to entry to nix as most of the road for doing real tasks has already been walked, documented, put in a module, and tested on production. This also means that in the short-term It's more cost efficient to dedicate my time to growing the framework than adding compatibility for a release of Nix that is still many months/years in the future
• It's better for the community to keep things simple and preferably high level: in other words $ m alias /whatever/you/need is a good thing. What I would like to achieve is a coherent Makes without feature flags, where documentation, examples, and real productions systems are on the same page
• We cannot feature flag the documentation, the documentation will also mention how to do things the makes way because doing it the makes way is how you can cover wide use cases, like pushing to binary caches after building. ¿How you do this with nix3 alone?
• In general we love microchanges and minimum viable changes that are commited to master the same day they are created so users start using them and providing feedback right away. So I'm open to dropping nix-stable tomorrow and start using nix-unstable for everything. The important thing though, is that it covers what we currently have in the docs, or at least a 95% of it (even with --impure or whatever flags are required for it to work seamlessly with today's scope) and then start working towards perfection
• main is always unstable during the current month, so we can do backward incompatibles changes as much as we want, no need for deprecation notice. This gives us a lot of space to innovate. The only requirement is that each commit represents a real working/useful version of Makes

[blaggacao]

I'd like to place 5 🚀 — one per bullet point 😄

[blaggacao]

• I think the best way is to make a "near-perfect" compat layer.
• A micro-change switch to nix3 would imply a trampoline to install a pinned version of nix3 based off of the normal nix installation (to keep easy installation & be able to pin nix fixes, if necessary). Also an option!

[dsalaza4]

I would try to make the new CLI on #989 as transparent and minimalistic as possible so it can be interchanged with direct nix commands. We'll see if this is actually feasible.

The biggest limitation I see here is the fact that (AFAIK) the nix command is STILL EXPERIMENTAL 😢, and we're also considering only supporting whichever nix CLI that is currently official.