Comments (14)
That sounds great, but I would actually like a negative bound:
--disable-strategy source
from cargo-binstall.
ok, sounds good
from cargo-binstall.
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 ?
from cargo-binstall.
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?
from cargo-binstall.
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.
from cargo-binstall.
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 (onlycargoinstall
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.
from cargo-binstall.
After #267 , I think we need an option to disable fallback to cargo
like --no-cargo-install-fallback
.
from cargo-binstall.
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.
from cargo-binstall.
As in do both include and exclude or just do the exclude? I'm happy with both of these tbh.
from cargo-binstall.
I'd prefer --disable-strategy
here since we are adding opt-out options.
from cargo-binstall.
Yes, that's ok for me.
from cargo-binstall.
Yeah, that sounds better.
from cargo-binstall.
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?
from cargo-binstall.
@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.
from cargo-binstall.
Related Issues (20)
- How to create new PR that triggers PR? HOT 3
- Use action `super-linter` in CI HOT 1
- Publish github action HOT 3
- `x86_64h-apple-darwin` failed to execute on my M1 HOT 10
- [Github Action][QEMU][aarch64] Install fails HOT 11
- How to binstall multiple binaries from a crate HOT 11
- Very slow checking of installed crate versions on `cargo binstall` HOT 3
- Don't clone repository if it already contains build artifacts HOT 2
- Use crates.io sparse index by default
- Binaries installed using `cargo-binstall` will not execute on NixOX HOT 4
- Optimize `--git` cloning local directory
- Check for glibc version when installing HOT 2
- `cargo-binstall` takes a lot of time to resolve package: Reqwest error: builder error: failed to parse header value HOT 28
- Verbose logs aren't very useful HOT 2
- Slow install possibly from downloads HOT 17
- Make github action more prominent in readme HOT 6
- Dependabot ignores simple-git
- cargo-binstall fallbacks to cargo-install with a fallback target instead of native target HOT 16
- Tries to build from source, although binary is present HOT 6
- Help with usage for crates with multiple binaries HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cargo-binstall.