Skip to content
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

make 0install the basis of the official Rust package manager #11888

Closed
thestinger opened this issue Jan 28, 2014 · 9 comments
Closed

make 0install the basis of the official Rust package manager #11888

thestinger opened this issue Jan 28, 2014 · 9 comments
Labels
P-medium Medium priority

Comments

@thestinger
Copy link
Contributor

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.

@lucab
Copy link
Contributor

lucab commented Jan 29, 2014

This seems a good field explore. I'm not a 0install expert, but I like the user capabilities and system manager integration.
OTOH, from what I have read this would solve only the binary-distibution problem, while source-building is still relying on other tools.

@thestinger
Copy link
Contributor Author

@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.

@pnkfelix
Copy link
Member

Packaging is not a 1.0 issue. Assigning P-high.

@lambda-fairy
Copy link
Contributor

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 lib.rs.

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 rustc, rustdoc et al., and publish them on the main site. The packaging tutorial has plenty of info on this.

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 rage) that generates feeds automatically, but that sounds a bit hacky. Any ideas?

I'll try to experiment further with 0install over the next few days. Stay tuned 🎵

@puredevotion
Copy link

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.

@lambda-fairy
Copy link
Contributor

we could write a converter to convert the current annotations to this XML format (possibly server-side)

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.

fork 0install and implement json.

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.

@lambda-fairy
Copy link
Contributor

I've given up with 0install, at least for now. Feel free to pick up where I left off.

@talex5
Copy link

talex5 commented Feb 14, 2014

Where did you get to, and what are you stuck on?

@thestinger
Copy link
Contributor Author

Cargo is going in a different direction.

arcnmx pushed a commit to arcnmx/rust that referenced this issue Jan 9, 2023
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:

![rust-analyser-feature](https://user-images.githubusercontent.com/10906982/208813167-3123e379-8fd5-4206-a4f4-5af1129565f9.gif)

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P-medium Medium priority
Projects
None yet
Development

No branches or pull requests

6 participants