Skip to content

Add "pub run --list" command to show all available executables #2 #1680

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

Merged
merged 3 commits into from
Aug 14, 2017

Conversation

akhomchenko
Copy link
Contributor

Good day.

This is a new iteration of #1323 based of #1427 as I was not able to push to that PR.

For now I've performed a merge with origin/master and updated the tests.
I'm going to address #1427 (comment)

@googlebot
Copy link

So there's good news and bad news.

👍 The good news is that everyone that needs to sign a CLA (the pull request submitter and all commit authors) have done so. Everything is all good there.

😕 The bad news is that it appears that one or more commits were authored by someone other than the pull request submitter. We need to confirm that they're okay with their commits being contributed to this project. Please have them confirm that here in the pull request.

Note to project maintainer: This is a terminal state, meaning the cla/google commit status will not change from this state. It's up to you to confirm consent of the commit author(s) and merge this pull request when appropriate.


await pubGet();
var pub = await pubRun(args: ['--list']);
expect(await pub.stdoutStream().isEmpty, isTrue);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if this is the best way

@kevmoo kevmoo requested a review from jakemac53 August 2, 2017 17:19
Copy link
Contributor

@jakemac53 jakemac53 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some additional small nits, it looks like the following still needs to be addressed from previous comments:

  • move to the pub deps command
  • add support for --dev, or add tests if it works

..addAll(entrypoint.root.immediateDependencies
.map((dep) => entrypoint.packageGraph.packages[dep.name]));

packages.forEach((Package package) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: prefer for (var package in packages) { ... } (see here).

return package
.listFiles(beneath: 'bin', recursive: false)
.where((executable) => p.extension(executable) == '.dart')
.map(p.basenameWithoutExtension);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Technically we should also check if these dart files have a top level main. You should be able to use parseDartFile from the analyzer to get the CompilationUnit, and then isEntrypoint from pub to do the check.

// If executable matches the package name omit the name of executable in
// the output.
return executables.first != packageName
? '${log.bold(packageName)}:${executables.first}'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like @nex3 preferred bold for executable names and not bold for package names (see here)

return e1.compareTo(e2);
});

return '${log.bold(packageName)}: ${executables.join(', ')}';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ditto, probably don't bold the commas though so you will need to wrap each executable in bold and join

@@ -22,13 +24,20 @@ class RunCommand extends PubCommand {
RunCommand() {
argParser.addFlag("checked",
abbr: "c", help: "Enable runtime type checks and assertions.");
argParser.addFlag('list',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To me once this moves to the deps command then --list is no longer descriptive enough (I would expect it to just list deps not executables). Maybe --list-executables?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually it looks like @nex3 suggested just --executables, that sounds good to me as well and is a bit less verbose.

@akhomchenko
Copy link
Contributor Author

I've addressed small issues. Moving command as flag to deps is the next step.

@jakemac53
Copy link
Contributor

looking good so far :)

@akhomchenko akhomchenko force-pushed the feature/1323 branch 2 times, most recently from 3cd5470 to 0976e90 Compare August 7, 2017 23:28
@akhomchenko
Copy link
Contributor Author

akhomchenko commented Aug 7, 2017

While I have some code to cleanup and tests to fix before review, I have some open questions. Thanks in advance.

}

/// The immediate non-dev dependencies this package specifies in its pubspec.
List<PackageRange> _nonDevDependencies(Package package) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should I move this to a public API of Package? E.g. here: https://github.com/dart-lang/pub/blob/master/lib/src/package.dart#L78 right after immediateDependencies?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that the dependencies getter is actually identical to this, so I would just use that.

Copy link
Contributor Author

@akhomchenko akhomchenko Aug 8, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does not include dependencyOverrides. Should I not care about them in such a case? (As they have the same binaries names)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes the dependencyOverrides are not relevant here. I don't think you can use that to add additional dependencies, or at least its not a supported use of that field afaik.

///
/// Returns file names without extensions.
List<String> _getExecutablesFor(Package package) => package
.listFiles(beneath: 'bin', recursive: false)
Copy link
Contributor Author

@akhomchenko akhomchenko Aug 7, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is already such a method in Package - executableIds. While I'm going to adapt _getExecutablesFor to use it, should _isDartExecutable be a part of executableIds?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, good question. To me it seems like executableIds should already be doing an equivalent _isDartExecutable check, but technically changing it to do that would be a breaking change.

The actual isEntrypoint check for instance doesn't actually catch all cases, so technically we could break existing packages so you could no longer run their executable. In reality my guess is it would not break anything, but its possible it would.

cc @kevmoo @munificent what do you think?


const _validMain = 'main() {}';

main() {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't found a good way to test the same things.

I was choosing between:

  • for loop
  • current approach
  • even more test-fn-generators

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could consider wrapping multiple calls to test in _testExecutablesOutput, something like this:

_testExecutablesOutput(String name, output, {devOutput}) {
  devOutput ??= output;
  for (var dev in [true, false]) {
    test(name + dev ? ' --dev' : ' --no-dev', () async {
      await pubGet();
      await runPub(
        args: ['deps', '--executables']
           ..addAll(dev ? ['--dev'] : ['--no-dev']),
        output: dev ? devOutput : output);
    });
  }
}

Up to you though, that pattern can make it hard to support the named args to test methods etc.


const _validMain = 'main() {}';

main() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could consider wrapping multiple calls to test in _testExecutablesOutput, something like this:

_testExecutablesOutput(String name, output, {devOutput}) {
  devOutput ??= output;
  for (var dev in [true, false]) {
    test(name + dev ? ' --dev' : ' --no-dev', () async {
      await pubGet();
      await runPub(
        args: ['deps', '--executables']
           ..addAll(dev ? ['--dev'] : ['--no-dev']),
        output: dev ? devOutput : output);
    });
  }
}

Up to you though, that pattern can make it hard to support the named args to test methods etc.

setUp(() async {
await d.dir(appPath, [
d.appPubspec(),
d.dir('binn', [d.file('foo.dart', 'main() {')])
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

extra n :)

@@ -190,56 +190,4 @@ main() {
test("are listed if --dev flag is set", _testAllDepsOutput('foo:bar'));
test("are skipped if --no-dev flag is set", _testNonDevDepsOutput('\n'));
});

group("lists dependencies overrides", () {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One thing that would probably be worth adding is a test where you have two versions of foo in different directories with different files under bin. Make the original dep be a path dep to one of them, and override it to the other one. You should get a list of the binaries in the overridden one not the original (pretty sure this would pass today).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll try it by I think it will not pass because of this

Actually, it will pass in case of --dev flag, but it will fail with --no-dev

Thats was my question here

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it should still pass, the name of the dependencies doesn't change which is all we actually use, then we look up the package in the PackageGraph which should be overridden version.

If it doesn't pass, then I was wrong and we will need to do some more work to support this.

@akhomchenko
Copy link
Contributor Author

akhomchenko commented Aug 9, 2017

So I think that PR is ready for a review, while I still do not like how tests are done.
If their style is ok for you, feel free to ignore my comment.

By the way, thank you for your review time and suggestions.

P.S. should I squash commit or you'll do it in case of merge?
(Probably it's better for me to squash my commits not to lose original author commit)

@jakemac53
Copy link
Contributor

@antonmoiseev can you please confirm here that you are ok with your original commit being contributed to this project?

@jakemac53
Copy link
Contributor

@gagoman I can do the squash/merge if you don't mind, I will retain the original author information though (otherwise if you squash and force push I have to re-review everything since its really a new commit and github doesn't handle the diffs well in that case).

@jakemac53
Copy link
Contributor

Actually I changed my mind, since this PR isn't very large and I can't push to your branch it makes sense for you to just do the squash of your commits, feel free to do that at any time.

* removed "run --list" command
* buffer is used to output executables
* tests were adapted to verify --dev/--no-dev flag
@akhomchenko
Copy link
Contributor Author

@jakemac53 done

@jakemac53
Copy link
Contributor

Everything LGTM, but unfortunately we have to wait for @antonmoiseev to respond here with his approval to merge the initial commit before this can be submitted :(.

@antonmoiseev
Copy link
Contributor

antonmoiseev commented Aug 14, 2017 via email

@jakemac53
Copy link
Contributor

Thanks @antonmoiseev!

@jakemac53 jakemac53 merged commit c4faeaf into dart-lang:master Aug 14, 2017
@akhomchenko akhomchenko deleted the feature/1323 branch August 14, 2017 18:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants