opt-out options

[somehowchris]

From a usability, testability and relyability point of view, I would like to be able to tell cargo-binstall which sources should be used.

With the current setup, all fallbacks are enabled by default. If I use --no-confirm, it will either use the crates binstall metadata, search on quickinstall or fallback to installing via cargo install. As this might be good for people who "just wanna install it", this means the goal of installing a pre-built binary might be missed.

What I do propose is not a falg to enable fallbacks, but rather flags to disable or exlude fallback:

• --no-third-party-sources to exlude third party installs
• --disable-cargo-install to just disable the fallback on cargo install

#133

[passcod]

I was thinking about this when adding those features, but could not figure out good ergonomics. The general idea of being able to more precisely control what will happen is good, to be clear, especially for script use. However, I don't think these proposed flags work well:

• They're very long
• They're inconsistently named. Both --no- and --disable-? That's not very intuitive.
• It's not going to scale. If more fallbacks are added, we'll need more flags. That's not necessarily a bad thing, but we probably want to figure out a solid pattern right now so adding more is straightforward.

As a point of discussion, perhaps something like this:

--use=crates.io,quickinstall,cargoinstall
--use=crates.io,quickinstall
--use=quickinstall

and some aliases:

• source for any source methods (only cargoinstall for now)
• bin for any binary methods (crates.io, quickinstall)
• 3rdparty for any 3rd party...

I'm not super happy with that scheme though, for these reasons:

• It flattens the "strategies" in one single list/category. In reality there's several dimensions:

  • where to find the package
  • where to find the version metadata
  • where to find the archive URLs or if we should install from source, and where to fetch that source

  For example, the crates.io strategy:

  • looks to crates.io (index or API currently, and possibly just API going forward) to find the package
    • or possibly locally, explicitly, when using the manifest option
  • fetches the list of versions from crates.io and resolves using crates.io rules
  • parses Cargo.toml for templates to render into archive URLs

  And quickinstall:

  • looks to crates.io, just like the above (in fact it's the same code)
  • also fetches versions the same way
  • completely ignores the Cargo.toml templating and builds its own URLs

  But thinking of a "install from git" strategy, it would:

  • look at a git repo to find the package
  • fetch git tags or guess at version
  • read the Cargo.toml there for any templating for the URL

  And the other "github releases strategy" could:

  • do similarly initially
  • find a github release from a crates.io version (or directly if going from a git repo)
  • but mostly ignore templating, and figure out the release URLs from a file list attached to a release

  However, exposing all this complexity to the user is not great either. I'm not sure what to do here yet.

• I think use is too generic

• This would enable only a "do these things exactly" and not e.g. "never pull from quickinstall"

In summary: idea is sound, more discussion needed.

[NobodyXu]

After #267 , I think we need an option to disable fallback to cargo like --no-cargo-install-fallback.

[passcod]

I was thinking of a --strategy metadata, quickinstall,source (as default) and then you can say e.g. metadata,source or metadata,quickinstall or just metadata.

That way it also makes it possible to reorder if you want to for some reason.

It's a bit simplistic as to what happens behind the scenes but probably the best we can do to balance UI with versatility.

e.g. when we add installs from guesstimating github releases we can call it ghreleases or something.

[NobodyXu]

That sounds great, but I would actually like a negative bound:

--disable-strategy source

[passcod]

As in do both include and exclude or just do the exclude? I'm happy with both of these tbh.

[NobodyXu]

I'd prefer --disable-strategy here since we are adding opt-out options.

[passcod]

ok, sounds good

[ryankurte]

i think the perk of a specific list of strategies is you can enforce ordering and easily show the default behaviour? like --strategy metadata,quickinstall,releases shows pretty well how it's going to search and could just end up in the CLI help... if we had that + an opt out would that work for you @NobodyXu ?

[NobodyXu]

Yes, that's ok for me.

[passcod]

I was thinking of names for the strategy, and had the thought that source was ambiguous, given the multiple meanings; I think compile instead is better?

[NobodyXu]

Yeah, that sounds better.

[NobodyXu]

I'm working on this and I got a question regarding --strategy.

i think the perk of a specific list of strategies is you can enforce ordering and easily show the default behaviour? like --strategy metadata,quickinstall,releases shows pretty well how it's going to search and could just end up in the CLI help...

Since we can enforce the order of which strategies are used, what if user specifies compile as the first strategy, which would make cargo-binstall equivalent to cargo-install?

Should we reject this and only accept compile as the last option?

[passcod]

Yes, that sounds reasonable. compile should be allowed as the only option, too; that wouldn't be very useful in principle but I could see it being used in scripts, for example.

[NobodyXu]

@somehowchris @ryankurte I've implemented this in #510, feel free to try it out and give feedback to me! I would merge this before releasing next version of binstall, which I might release in roughly 2-3d.