bsutton
commented
4 years ago So I'm thinking that dcli create should create a pubspec.yaml with the necessary dependencies.
dependency injection sounds nice but the fact that you can't use dev tools is a pain. If we are creating a pubspec.yaml by default then there is perhaps little reason to support dependency injection.
Does the dcli compile actually provide any benefit?
- provides a consistent cli for working with dcli. The option to install to the path is also nice.
dcli compile fred.dartvs
cd .. pub global activate <package> -source=path
So I think dcli is useful and should be kept.
Do annotations have a place? The core reason for annotations is so that you can have a 'single' file that you can copy between machines. You can copy a compiled script between machines but this isn't necessarily what is wanted. So may be the annotation is left as a poor cousin. You use dcli merge to create the annotation but its only for these special use cases and mostly you prompt using a pubspec.yaml.
Lets now discuss dependencies. Dependencies allow you to create a script with out a pubspec.yaml and you get a default set of dependencies. The problem is that development tools don't support this concept. So to do dev (unless you are using vi) you really need the dependencies in the local directory.
We could look at creating an extension for vscode to handle our auto injection but this really feels like more work than necessary.
If dshell create creates all the necessary files then the reality is the people probably don't care about having a single file like bash. Do annotations just become a transport mechanism? If thats the case we may as well have a option that just creates a zip file.
e..g dcli package fred.dart
- creates fred.dcli
- this contains the pubpsec.yaml and all of the non-generated file (perhaps .lock) in a zip file that can be copied to another mechine. dcli expand fred.dcli creates the expanded package. Perhaps we could even make the package runnable: e.g. ./fred.dcli - unzips and runs the app.
In the end I don't use the annotations and I've not really used the .dependencies especially if the dcli create created the pubspec.yaml.
So is the concept of a virtual project useful? Virtual projects came about to support annotations and dependencies.
Dcli is intended to allow a user to comple a local script without having to provide a pubspec.yaml.
dart and dart2native has a set of rules about where it will look for a pubspec.yaml file.
Essentially both of these apps will scan up the directory tree until they find a pubsec.yaml. And the apply the settings in that file.
An aim of dcli is to make it easy to grow an up from a dcli script to a full blow console app. As such we aim to follow the same rules a dart.
To this end when running dcli compile or clean we need to scan up the parent tree for a pubspec.yaml.
Currently we only do this if a prescribed directory is below the pubspec.yaml directory (bin, test, example) but it looks like this logic is incorrect.y
As such dcli needs to look for a pubspec.yaml in current and then any parent directory. If its finds one then the script is no longer a virtual script. So the exception to this should be an annotated script. If we have an annotation then we should use that script.
As such we need to remove the list of prescribed directories (as any directory is just fine). We also need to check that we are correctly determining each of the types of pubspec
1) annotated - if the script has a @pubspec annotation 2) virtual if the current directory and no parent directory contain a pubspec.yaml. 3) standard - if we find a pubspec in the local directory or an parent directory. 4) local - you include your pubspec.yaml in the same directory as your script.
Actually there is a difference between Standard and Local. If dart finds a pubspec.yaml in a parent directory then it will ignore the local pubspec.yaml. DCli on the other hand will actually use the local pubspec.
The problem with DCli's approach is that tools like vscode follow darts rules and as such we make it difficult to use vscode and Dcli for a local project.
dcli split is also questionable as it essentially works to create a local pubspec..
Local will work if there is no parent pubspec.
Perhaps we should have dcli give off a warning if there is a local pubspec and a standard pubspec. Same would go for the split if it was going to cause a problem.
I think essentially the recommendation is that you should not put a dcli script under a directory that has a standard dart structure.
If you have a set of scripts it should either has a shared (parent) pubpsec.yaml or use annotations. There is probably nothing wrong with a shared parent script. The downside is that if you want to move a script to another machine it is no longer stand along. We could fix this via the merge command. The merge command is already intended to create an annotation it just needs to follow the same rules when looking for the pubspec.yaml.