Graydon Hoare scrisse: > This should also permit mapping such identifiers to filesystem paths > in GOPATH-like workspaces, permitting local workspaces overlaid on > global ones and branching (via your VCS -- it does versions!) inside > local workspaces and whatnot. In case it's not clear from the sketch > here, it's very similar to what Go does -- I think they did a very > tidy job and I'm interested in copying its good parts. It feels like > we didn't quite hit the mark with cargo and this is an important > thing to get right. > > That said, I'm interested in some feedback before we get too far into > it, to make sure we aren't making serious mistakes or missing issues > that people feel are unpleasant about URL-centric schemes. > > Any thoughts? Notes on other failure modes in package managers? > Requests for ponies? I'd prefer specificity in response, if you can > manage it. We all know package management is "generally miserable", > but if you can describe _exactly_ how things go wrong in other > systems and what we should be trying to avoid, or aiming for, that'd > be good.
There are many good points in this proposal, the sensible-defaults and the plugin escape-hatch are the foremost. However, there are some (to my eyes) pitfalls here and more notably in the GO way that are not really comfortable for me, so I'd like to chime in. As we are talking about a package manager, I'd like to have it more focused on building system-integrated overlays over than replacing common package management. Having to handle N local big-workspaces vs. a central system plus minimal overlays may be cumbersome, eg. in a typical high-rush security push. System package managers also handles many subtitles (like enforcing signatures and checksums checks, handling conflicts, managing inter-languages/FFI dependencies, running privileged triggers, update system-wide caches) which I'd like to retain and not re-implement, side-by-side with local rustpkg overlay handling. With your URL-proposal and Zack's related mail, I got some taste of "screw versioning and API/ABI contracts" or "let's deploy everything locally out of github", which I fear may hurt in the long term on the manageability, maintenance and scaling side. I clearly see the benefits for devs of this proposed model, but I hope long-term ops won't be sacrificed for that. I may be biased and may have missed some rust-peculiar points, but I feel more confident with a model where package archives and package managers are not too coupled and can gracefully cohabit alongside with system-wide packages, over a "let's keep everything local and static" à-la GO. Cheers, Luca -- .''`. | ~<[ Luca BRUNO ~ (kaeso) ]>~ : :' : | Email: lucab (AT) debian.org ~ Debian Developer `. `'` | GPG Key ID: 0x3BFB9FB3 ~ Free Software supporter `- | HAM-radio callsign: IZ1WGT ~ Networking sorcerer
signature.asc
Description: PGP signature
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
