If you're going to support go-style importing of external packages in git repos, it's worth reading kana's ideas concerning version tags. Pasting the relevant bit in:
Plugins must follow the versioning pocilies of RubyGems and have "version" tags in their repositories. For example, if there is the version 1.2.3 of a plugin, its repository must have the tag 1.2.3, and the files of the version 1.2.3 can be checked out via the tag 1.2.3. In other words, plugins which do not have proper tags are not installable. This is an intentional design. Because: It's not possible to determine whether two versions are compatible or not without "version" tags. Compatibility is a big problem to resolve dependencies of plugins. For example, if plugin A requires plugin X 1.2.3 or later while plugin B requires plugin X 2.0 or later, it's not possible to use A and B at the same time. Such problems should be detected before installing plugins. Git mirrors by vim-scripts.org are tagged with version numbers. Some Git repositories might not have "version" tags. Such plugins are not ready to use for everyone. So that it should not be installable. https://www.relishapp.com/kana/vim-flavor/docs/philosophy martin On Tue, Feb 19, 2013 at 5:05 PM, Graydon Hoare <[email protected]> wrote: > Hi, > > We've recently replaced the cargo package manager with a new (very > young) tool called rustpkg; in the process it's (temporarily) broken > most of the packages installable through cargo, but we'll be fixing this > up before the next release. > > The main new feature of rustpkg is that it permits writing custom build > logic (and custom build tasks) in rust itself, as an escape hatch: if > there's a file called pkg.rs in a package repository it is compiled, > linked against rustpkg itself and run for various tasks. > > That's a nice feature and all, but we don't want to force (or even > _suggest_) use of the escape hatch by default. We'd like rustpkg to do > most things by inferring-sensible-defaults when looking at a repository. > In particular, building all the most obvious / findable binary and > library crates contained therein, based on simple rules. Preferably > rules that don't require parsing all the files in the repo and sorting > them into a module-graph just to figure out the targets. There might be > a lot of files (cf. src/test/run-pass/*.rs) > > The simplest rule I've come up with is based on a convention for chosen > filenames and their immediately-containing dir names. Specifically the > names "lib.rs" for libraries and "bin.rs" for binaries: > > foo/lib.rs ==> build libfoo-<hash>.so / .dll, a library > foo/bin.rs ==> build foo / foo.exe, an executable > > This is a convention that'll require a certain amount of reorganization > to existing code, but it permits multi-library / multi-binary packages > in a single source repo, which is an important use-case. Lots of time > people want >1 crate in the same git tree. Moreover it makes for a > pretty simple naming heuristic that can be derived directly from > URL-path-fragment package identifiers, such that: > > extern mod foo (id = "github.com/graydon/foo"); > > will pick up a single-library package, assuming there's a single file > lib.rs in that repo, and give it the name libfoo-<hash>.so, because > 'foo' is the immediate parent-dir of the lib.rs file. Whereas: > > extern mod foo (id = "github.com/graydon/foo/thing"); > > will look for a thing/lib.rs dir-and-stem inside the > github.com/graydon/foo repo, and build-and-link _that_ into > libthing-<hash>.so. > > 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. > > Thanks, > > -Graydon > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
