dart-lang / cli_util Goto Github PK

Trying to standardize on https://github.com/dart-lang/io/blob/master/lib/ansi.dart

To follow standard naming and code style, sdkPath should be a getter and not start with get.

I recommend deprecating the current function and adding a getter, then removing in the next "major" version (meaning minor version increment, since we're pre 1.0.0).

It looks like 2fbb4eb introduced a regression where the ANSI progress spinner doesn't spin. See dart-lang/sdk#45891 to context. We should revert that change / apply a fix.

Are there any plans to support dart's null safety?

I can't find an installation of Dart where version is a directory, yet that is what is expected in _isSdkDir. This function used to (pre 0.1.0) just test whether a thing existed named version.

Indeed on my Mac Homebrew installation, version is a file:

$ file /usr/local/Cellar/dart/1.24.0-dev.6.9/libexec/version
/usr/local/Cellar/dart/1.24.0-dev.6.9/libexec/version: ASCII text
$ cat /usr/local/Cellar/dart/1.24.0-dev.6.9/libexec/version
1.24.0-dev.6.9

So folks know what version constraint to use...

The Logger class is a great abstraction over dart:io stdout and stderr, but if I want to log some text without a newline, I cannot use Logger.

This means that I cannot catch such writes when mocking Logger with a fake Logger in tests.

Logger itself uses stdout.write in its indeterminate progress indicator (grep for stdout.write).

I think Logger should provide other commonly used methods from stdout, an IOSink, like write(), writeCharCode(), and writeln().

The existence of bin/dart would be an equally cheap test, I think.

cli_util is a super non-descriptive name for a library that only provides a simple, standardized way to get the current SDK directory.

This might give anyone looking through packages the impression that this is something more useful than it is :) The majority of Dart command-line apps is not using the Dart SDK explicitly, I would assume.

https://travis-ci.org/dart-lang/cli_util/builds/395142141

I think it would be useful if this package supported more customizable Progress to display percentages, counts, reporting messages, etc. I couldn't find any package that provides this kind of general progress indicator.

Currently we check for the presence of a version file; however, some builds of the sdk do not include a version file.

This might be more a bug for which than for cli_util, though.

The which subcommand skips executables that have permissions to execute as a user but not the world. This seems to be intentional because there is no API to validate that the current user is the same as the owner of the file (see the TODO at https://github.com/seaneagan/which.dart/blob/master/lib/src/is_executable.dart#L28). Maybe we should allow it and delegate to the OS to fail with permission errors if the user and the owner don't match?

For others running into this limitation, one way to work around it is to do

chmod a+x `which dart`

See https://codereview.chromium.org//1145053002. Possibly no adjustments necessary for this library? But something to be aware of -

dart-lang/test@57355ed#commitcomment-11597295

Seems this prevents this package to be used for its primary use case.

Hi there,

My Flutter application uses the analyzer package, and I'm finding that after a upgrade, our tests are now failing.

It looks like getSdkPath wasn't designed to accommodate a Platform.resolvedExecutable of flutter_tester (which lives under bin/cache/artifacts/engine/{platform}/flutter_tester

I'm running analyzer 0.39.17, and cli_util 0.2.0.

Here's the exception:

FileSystemException(path=/Users/shyndman/work-code/flutter/bin/cache/artifacts/engine/version; message=Cannot open file)
  package:analyzer/file_system/physical_file_system.dart 194:7               _PhysicalFile.readAsStringSync
  package:analyzer/src/dart/sdk/sdk.dart 428:12                              FolderBasedDartSdk.languageVersion
  package:analyzer/src/context/builder.dart 257:40                           ContextBuilder.findSdk
  package:analyzer/src/context/builder.dart 200:19                           ContextBuilder.createSourceFactory
  package:analyzer/src/context/builder.dart 114:16                           ContextBuilder.buildDriver
  package:analyzer/src/dart/analysis/context_builder.dart 92:37              ContextBuilderImpl.createContext
  package:analyzer/src/dart/analysis/analysis_context_collection.dart 54:36  new AnalysisContextCollectionImpl

Any suggestions?

See the following bug and fix in the dartdev pkg:

dart-lang/sdk#40808

https://dart-review.googlesource.com/c/sdk/+/137846

I cannot undestand which help provide this library?
Only "getSdkDir"?
Let's look at the provided help.

In order of appereance

int index = cliArgs.indexOf('--dart-sdk');
OK

if (Platform.environment['DART_SDK'] != null)
BAD
What happened if the environment['DART_SDK'] refers to 32-bit SDK but we run the 64-bit Dart VM.
This may cause a lot of problems.

Directory sdkDirectory = new File(Platform.executable).parent.parent;
OK

String executable = whichSync('dart', orElse: () => null);
??? I don't know how it work

Also:
bool _isSdkDir(Directory dir) => _joinFile(dir, ['version']).existsSync();

Why not test that exists files that related only to Dart SDK?
Eg. "include/dart_api.h"
I don't think that it can exists somewhere outside of Dart SDK.

Perhaps a use-case for cli_util? Many commands line tools need some simple ansi output, logging, and indeterminate progress display. These tools either all roll their own or do without. cli_util could be a good place for some simple, prescriptive console tool output.

@pq

// test.dart
import 'package:cli_util/cli_util.dart';

main() {
  print(getSdkPath());
}

dart-sdk/sdk$ out/ReleaseX64/dart test.dart
/usr/local/google/home/sigurdm/projects/dart-sdk/sdk/out

That is not really a helpful directory.
I am not sure where the out/ReleaseX64/dart binary reads its corelibs from, but I think that should be the returned directory.

This might be a duplicate of: #38 - not sure

Like:

• responding to --version
• responding to --help
• printing usage text (decorating the args usage text slightly)
• creating an ArgsParser object

Probably architected as an abstract template class?

@pq