more useful rustpkg init

[minhnhdo]

This PR modifies the behavior of rustpkg init.

rustpkg init now accepts two more arguments, the first is the type of package to initialize (bin or lib), and the second is the package name. Instead of initializing a workspace in the current directory, rustpkg init now initializes a workspace under the directory with the same name as the supplied package name. In addition, it also creates some default crates (i.e. lib.rs or main.rs) under src/<package-name>/.

E.g. rustpkg init lib awesome_lib will create the following directory tree in the current directory.

awesome_lib/ 
 - bin/
 - build/
 - lib/
 - src/
    - awesome_lib/
       - lib.rs

The content of lib.rs is the following.

pub fn get_answer() -> int {
    42
}

EDIT: test.rs is no longer generated.

[huonw]

FWIW, mod lib; in test.rs will not be correct in the common case, it would require writing all use statements in the package as relative statements since the crate root goes up one level when testing.

[huonw]

(Also, how rustpkg runs tests is still undecided (#9003), so I think it'd be better to not "promote" the current sub-par situation by having it generated by default.)

[minhnhdo]

@huonw could you please elaborate the testing behaviour or point me to some materials on it? I'm asking because with that layout, I can still run rustpkg test awesome_lib inside awesome_lib/.

[huonw]

@mrordinaire I don't know any more than listed on #9003, but, an example:

lib.rs:

use foo::useful;

pub mod foo;

pub fn more_useful() { useful() }

foo.rs

pub fn useful() {}

test.rs

mod lib;

The mod lib will mean that the use foo::useful line is invalid (since there is no foo in test.rs, which the root of the crate) and so compiling test will fail.

---

So what I'm saying is we shouldn't be dictating a testing structure until #9003 is solved, i.e. don't create a default test.rs.

[klutzy]

I've thought the bin/build/lib directories are for workspaces, not for source directories (aka git repos).
Similarly, I think lib.rs doesn't need to be inside awesome_lib/. librustpkg/testsuite/pass/src/ contains some sample "repos", and some repos (e.g. hello-world and fancy-lib) doesn't have recursive directory structure.
That being said, I don't know what is "standard" way to organize source directory. I'm just guessing now.

[huonw]

@klutzy isn't the point of rustpkg init to create a workspace (and in this case, it's being extended to automatically add a one default package to the workspace)?

[klutzy]

@huonw Ah right, I was wrong.

[metajack]

I'm -1 on this patch as is.

1. rustpkg init is supposed to create a workspace. For example, you'd use this to create a place to work on some collection of rust packages like Servo. rustpkg init and then rustpkg install github.com/mozilla/servo
2. A better name for something that created a package scaffolding is rustpkg new PKGID which would create just the package dir and not a workspace.
3. Many other similar tools add a test as well, but this test is bad because it will start failing as soon as you make any change to the package. Whatever test is added to the scaffolding should always pass (or always fail I suppose depending on your point of view).

[minhnhdo]

@huonw Thank you for the clarification. I tried it and it really didn't work.
@metajack if this PR reverts to only creating a package directory, to the user, the amount of typing wouldn't be justified by the handicapped capability (rustpkg new PKGID versus mkdir PKGID). test.rs is added in order to encourage writing tests by means of examples. When the test fails because of modifications or by default, the user can always delete the file or comment out the test. Thus, by adding test.rs, we risk confusing the new user at first in exchange for better engineering practices in the community. This, I think, is worthwhile.

[alexcrichton]

Closing this temporarily in an attempt to un-stick bors.

[alexcrichton]

Hm, it appears that bors does not like this pull request, would you mind reopening again? Bors normally has no problems with fresh pull requests.

[minhnhdo]

@alexcrichton done. The new PR is now #10760

[alexcrichton]

Sorry about that, but thanks!