[replying on-list, with Jordi's permission] On Tue, Aug 6, 2013 at 2:37 AM, Jordi Boggiano <j.boggi...@seld.be> wrote: > Heya, > > Someone mentioned you are the one doing most things on rustpkg these > days, so here comes my feedback after reading > https://github.com/mozilla/rust/blob/master/doc/rustpkg.md - I hope it's > a bit valuable :) > > - I'm not sure if standardizing on main.rs/lib.rs files is the best > idea? It seems like the language itself now loads foo/mod.rs for `mod > foo;`, and #[link] can tell you if the file is to be built as a binary > or lib as far as I understand. So maybe it'd be best to just have mod.rs > for packages too? On the other hand having two files might allow you to > have a package that can both contain a library and a binary. That'd be > kinda neat for some things.
We're trying to move away from requiring attributes inside files, like #[link], and trying to make rustpkg infer as much as possible about the build process from directory structure. You'll still be able to use #[link] to override rustpkg's inference, but the goal is that you should never have to write it. (Although, if we did use mod.rs instead of main/lib/test/bench, it would still be possible to have both a library and binary in one package -- you would just have to put them in different subdirectories.) > > - "When building a package that is not under version control, or that > has no tags, rustpkg assumes the intended version is 0.1." - this sounds > pretty bad to me. I think it should in that case read the vers field in > #[link] or something. Yeah, that was kind of a placeholder. It's not documented yet, because it's not implemented yet, but you should be able to specify a version inside the file if you want to -- see https://github.com/mozilla/rust/issues/8239 (the bug is about the name attribute, but the same goes for "vers"). > > - "When building a package that is in a git repository, rustpkg assumes > that the most recent tag specifies the current version." - I can see > that one backfiring on large projects where you maintain two branches at > the same time. Say you make a 2.0.2 release but then you create a > security update for the old branch and tag 1.5.4. If rustpkg suddenly > thinks 1.5.4 is the most current version we'll have issues. It really > should work based on semver IMO. It's a great way to do sane versioning > and starting a new ecosystem without semver would be extremely sad. > That's a reasonable point. rustpkg has just the beginning of semver support right now, but the plan has always been to support semver. Again, it's not documented because it's still to-do :-) > In any case, I may not be able to help much with development because I'm > already quite busy with other things, but I've been leading the > development of Composer [1] - a PHP dependency manager - for the last > two years. It is - much like rustpkg - fully VCS-based when it comes to > finding package releases, so I hope I can at least help on a higher > level. If you want to discuss anything feel free to ask, I'm also on IRC > as Seldaek. I'll take a look at Composer. Thanks for the feedback! Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt "Being queer is not about a right to privacy; it is about the freedom to be public, to just be who we are." -- anonymous, June 1990 _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
