dylan-lang / deft Goto Github PK

I've decided I really like putting library source code in a subdirectory called "sources" or even (shudder) "src", because of the nice, tidy feeling it gives to the top directory, making any top-level files like README easily visible.

Let's make dylan new library do this.

In particular, _test, _build, and _packages should be ignored.

17:52:55 ~/dylan/workspaces/dylan-tool (dev*) 
$ dylan-tool-app update
Downloaded pacman-catalog@master to /home/cgay/.local/state/dylan/_packages/pacman-catalog/master/src/
Downloaded [email protected] to /home/cgay/dylan/workspaces/dylan-tool/_packages/strings/1.1.0/src/
Downloaded [email protected] to /home/cgay/dylan/workspaces/dylan-tool/_packages/command-line-parser/3.1.1/src/
Downloaded [email protected] to /home/cgay/dylan/workspaces/dylan-tool/_packages/uncommon-dylan/0.2.0/src/
Downloaded [email protected] to /home/cgay/dylan/workspaces/dylan-tool/_packages/json/1.0.0/src/
Downloaded [email protected] to /home/cgay/dylan/workspaces/dylan-tool/_packages/logging/2.1.0/src/
Downloaded [email protected] to /home/cgay/dylan/workspaces/dylan-tool/_packages/sphinx-extensions/0.2.0/src/
Downloaded [email protected] to /home/cgay/dylan/workspaces/dylan-tool/_packages/testworks/2.0.0/src/
Downloaded [email protected] to /home/cgay/dylan/workspaces/dylan-tool/_packages/regular-expressions/0.2.0/src/
WARNING: LID file /home/cgay/dylan/workspaces/dylan-tool/_test/cgay-20230528-175015/test-parse-lid-file--lid-header/child.lid has no (transitive) 'Files' property.
WARNING: LID file /home/cgay/dylan/workspaces/dylan-tool/_test/cgay-20230528-175015/test-parse-lid-file--lid-header/parent.lid has no (transitive) 'Files' property.
WARNING: LID file /home/cgay/dylan/workspaces/dylan-tool/_test/cgay-20230528-175146/test-parse-lid-file--lid-header/child.lid has no (transitive) 'Files' property.
WARNING: LID file /home/cgay/dylan/workspaces/dylan-tool/_test/cgay-20230528-175146/test-parse-lid-file--lid-header/parent.lid has no (transitive) 'Files' property.
WARNING: Library "abc" has multiple .lid files for platform "x86_64-linux".
  /home/cgay/dylan/workspaces/dylan-tool/_test/cgay-20230528-175146/test-source-file-map--included-lid/abc.lid
  /home/cgay/dylan/workspaces/dylan-tool/_test/cgay-20230528-175015/test-source-file-map--included-lid/abc.lid
Registry will point to the first one, arbitrarily.
WARNING: Library "foo" has multiple .lid files for platform "x86_64-linux".
  /home/cgay/dylan/workspaces/dylan-tool/_test/cgay-20230528-175146/test-parse-lid-file--lid-header/parent.lid
  /home/cgay/dylan/workspaces/dylan-tool/_test/cgay-20230528-175146/test-source-file-map--basics/foo.lid
  /home/cgay/dylan/workspaces/dylan-tool/_test/cgay-20230528-175015/test-parse-lid-file--lid-header/parent.lid
  /home/cgay/dylan/workspaces/dylan-tool/_test/cgay-20230528-175015/test-source-file-map--basics/foo.lid
Registry will point to the first one, arbitrarily.
WARNING: Library "abc-test-suite" has multiple .lid files for platform "x86_64-linux".
  /home/cgay/dylan/workspaces/dylan-tool/_test/cgay-20230528-175146/test-source-file-map--included-lid/abc-test-suite.lid
  /home/cgay/dylan/workspaces/dylan-tool/_test/cgay-20230528-175015/test-source-file-map--included-lid/abc-test-suite.lid
Registry will point to the first one, arbitrarily.
Updated 27 files in /home/cgay/dylan/workspaces/dylan-tool/registry/.

Workspaces should support multi-platform development. For example using a shared NFS mount for sources and a different _build directory on each platform.

It might be the case that if the user sets OPEN_DYLAN_USER_ROOT everything will Just Work, but this should be tested. Leaving this bug here as a reminder.

Registry generation always writes to a platform specific directory so as long as dylan update is run on each platform the registry part should work.

So that it's possible to use non-git packages, or get packages on a machine that doesn't have git installed.

There is some overlap between what the project-wizard library does and dylan new application/library. Figure out whether code can be usefully shared between them. Currently project-wizard is win32-only and is itself a DUIM application so I suspect at a minimum it would need to be broken into two libraries.

Does project-wizard generate any test code? If not, we can share in both directions.

Notice the output is "dylan-tool-app library", not "dylan-tool-app new library".

$ dylan-tool-app help new library
Create a new shared library and its test library.

Usage: dylan-tool-app library [options] NAME [DEPS] ...

dylan update --latest-deps (or similar flag name) should rewrite dylan-package.json with dependencies updated to the latest versions. This is toil that needs to be done relatively frequently so it should be made easy.

Possibly dylan-status should also show what deps are behind as well, but for now dylan update can fix it and git diff can show the result.

It should remove and regenerate the registry from scratch.

(When we have build and test they should also have this option but it will remove _build.)

It shouldn't be necessary to publish a package in the public catalog in order to use it as a dependency. An organization might want to develop a suite of internal packages, for example.

Git submodules could be used to accomplish this, but then you'd be using git submodules, and nobody wants that. Also they wouldn't participate in dependency resolution.

Not sure how I want to handle this yet. Support multiple catalogs with precedence order probably?

dylan build --clean --all invokes dylan-compiler multiple times, each time with the -clean option. Should only pass -clean on the first invocation.

When a new library or application is created, create a '.gitignore' configured for the OpenDylan language.

If you run dylan update in the dylan-tool directory itself, it writes platform-specific registry files that shadow the generic registry entries that are under version control. Either it should prompt the user "ok? (yes/no)" or just abort with a message.

dylan new application --simple foo needn't include Testworks as a dev dependency since no test suite is created.

Just noticed that Files: is allowed to be specified multiple times in one LID file, and I'm sure I didn't add support for that. Low priority.

Fully document dylan-package.json

While publishing a new version of lsp-dylan I checked the diff it created in pacman-catalog...

00:51:03 ~/dylan/workspaces/pacman-catalog (lsp-dylan*) 
$ git diff
diff --git a/v1/ls/p-/lsp-dylan b/v1/ls/p-/lsp-dylan
index 4da47c0..11ceb13 100644
--- a/v1/ls/p-/lsp-dylan
+++ b/v1/ls/p-/lsp-dylan
@@ -1,14 +1,28 @@
 {
-  "category": "development tools",
-  "contact": "[email protected]",
-  "description": "Language Server Protocol",
-  "keywords": ["lsp"],
+  "category": "",
+  "contact": "",
+  "description": "Language Server Protocol implementation",
+  "keywords": [],
   "name": "lsp-dylan",
   "releases": [{
+                 "dependencies": ["[email protected]",
+                                  "[email protected]", "[email protected]",
+                                  "[email protected]", "[email protected]"],
+                 "deps": ["[email protected]", "[email protected]",
+                          "[email protected]", "[email protected]",
+                          "[email protected]"],
+                 "dev-dependencies": ["sphinx-extensions", "testworks",
+                                      "vscode-dylan"],
+                 "license": "Unknown",
+                 "url": "https://github.com/dylan-lang/lsp-dylan",
+                 "version": "0.2.0"
+               },
...

Notice that it zeroed out the values for category, contact, and keywords, and changed the license from MIT to Unknown.

This could be a common newb mistake. Checkout some repo that has no dylan-package.json, run dylan update, and just see "The registry is up-to-date" even though it did nothing because there are no active packages. Should warning if no active packages were found, even if not doing verbose output.

This would avoid having to list all the platforms and would allow us to write the registry entry in the registry/generic/. It's also nice for self-documenting purposes compared to "here's a list of platforms; you decide if it's complete".

As mentioned in dylan-lang/opendylan#964

We're going to need this to know which platforms to test on when new versions are published. c.f. objc-dylan

Or we could scan the package's LID files for the Platforms: header to figure it out? That would avoid the data duplication but would it cause other problems?

For example, dylan build -a in a Testworks workspace on Linux tries to build testworks-gui.

For later... It might be worth having a dylan new [dev] dependency pkg1 [pkg2 ...] subcommand since it could

• verify that the dep exists
• verify that the dep doesn't conflict
• prevent simple syntax errors in the package file

Support SemVer pre-release versions

Probably want to leave the submodule stuff there for now at least.

dylan deps foo -- show transitive dependencies of foo

dylan deps foo --reverse -- show who depends on foo

dylan deps foo --reverse --indirect -- also show indirect users of foo

Or something like that. Command name and flags up for debate.

1. Add dep [email protected] to some project
2. dylan update
3. Remove dep strings from the pkg.json file
4. dylan update
5. There is still a registry entry for strings that points to the strings 1.0 package.

If strings is still being used it should be picked up from the Open Dylan installation or (if it's not in the OD install) the user should get an error.

Conceptually, we should simply remove the entire registry directory before dylan update generates a new one. What I would prefer is to actually show the changes that were made, so just note the files that exist at the start and remove any that don't get overwritten.