-
Notifications
You must be signed in to change notification settings - Fork 13.3k
make 0install the basis of the official Rust package manager #11888
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
This seems a good field explore. I'm not a 0install expert, but I like the user capabilities and system manager integration. |
@lucab: It's fully capable of being used as both a binary and source-based package manager. It is not a build system, if that's what you mean. |
Packaging is not a 1.0 issue. Assigning P-high. |
I had a cursory look into 0install today. Here's what I've found. Every 0install package is defined by an XML metadata file, called a "feed". The feed contains the package name, description, version, dependencies &c -- the kind of metadata we already provide in Dependencies are specified similarly to rustpkg -- using URLs -- but instead of linking to the git repository, we link to the appropriate XML feed instead. The 0install resolver recursively downloads these feeds, building a graph of dependencies, before running a SAT solver on the whole lot. Packages are installed in a global cache, keyed by a checksum of the package contents. This checksum is included in the feed. We should eventually remove the hash suffixes from our library names, since 0install makes this system redundant. A good first step would be to write feeds for Next, we should figure out how to build Rust packages with 0install -- maybe write a cheat sheet mapping rustpkg annotations to 0install elements. The only issue I have is usability. 0install's XML format is much harder to write than our current annotations, and has too many degrees of freedom. We can solve this by writing a wrapper (let's call it I'll try to experiment further with 0install over the next few days. Stay tuned 🎵 |
I had a chance yesterday night to explore 0install, after a discussion earlier in #10041. There are a few ways around the issues you mentioned concerning the XML files: we could implement a linter to check and bound the DOF, we could write a converter to convert the current annotations to this XML format (possibly server-side), or fork 0install and implement json. I must say that 0install looks very complete, but I haven't had the chance/time to really use it. I'm looking forward to your experimentations. |
I did consider this idea, but it's very brittle. You'll need to run this hypothetical converter every time you modify your own projects, taking care to keep it in sync with your crate file. On the server side: 0install doesn't support downloading git repositories directly, only tarballs. So we have to serve archives from the server as well. There's also a leaky abstraction here. Despite our best attempts at hiding the 0install syntax, the user will need to learn about the format eventually, when they run into the limits of our annotation system. Then they'll have two syntaxes to worry about.
That's possible, and a bit more elegant, but difficult. The existing code seems to be tightly coupled to the XML representation, so it'll take a bit of hacking to work. |
I've given up with 0install, at least for now. Feel free to pick up where I left off. |
Where did you get to, and what are you stuck on? |
Cargo is going in a different direction. |
Add action to expand a declarative macro once, inline. Fixes rust-lang#13598 This commit adds a new r-a method, `expandMacroInline`, which expands the macro that's currently selected. See rust-lang#13598 for the most applicable issue; though I suspect it'll resolve part of rust-lang#5949 and make rust-lang#11888 significantly easier). The macro works like this:  I have 2 questions before this PR can be merged: 1. **Should we rustfmt the output?** The advantage of doing this is neater code. The disadvantages are we'd have to format the whole expr/stmt/block (since there's no point just formatting one part, especially over multiple lines), and maybe it moves the code around more in weird ways. My suggestion here is to start off by not doing any formatting; and if it appears useful we can decide to do formatting in a later release. 2. **Is it worth solving the `$crate` hygiene issue now?** -- I think this PR is usable as of right now for some use-cases; but it is annoying that many common macros (i.e. `println!()`, `format!()`) can't be expanded further unless the user guesses the correct `$crate` value. The trouble with solving that issue is that I think it's complicated and imperfect. If we do solve it; we'd also need to either change the existing `expandMacro`/`expandMacroInline` commands; provide some option to allow/disallow `$crate` expanding; or come to some other compromise.
Zero Install is a robust cross-platform package manager. It will be able to handle external dependencies on native libraries well and there are already many packages available.
It has support for dependency handling, package signing, tooling for maintaining repositories, coexisting package versions, and even graphical tools. It also has optional integration with the system package manager via PackageKit to avoid duplication where possible. I don't think we should try to rebuild this ourselves.
The text was updated successfully, but these errors were encountered: