dylan-lang / deft Goto Github PK
View Code? Open in Web Editor NEWThe Dylan CLI
License: MIT License
The Dylan CLI
License: MIT License
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
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.
dylan update
dylan update
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.
Library "iop-protocol" has multiple .lid files for platform "x86_64-linux".
/home/cgay/dylan/workspaces/od/opendylan/sources/corba/orb/orb/../iop-protocol/iop-protocol.hdp
/home/cgay/dylan/workspaces/od/opendylan/sources/corba/orb/iop-protocol/iop-protocol.hdp
/home/cgay/dylan/workspaces/od/opendylan/sources/corba/orb/core/../iop-protocol/iop-protocol.hdp
/home/cgay/dylan/workspaces/od/opendylan/sources/corba/orb/iiop/../iop-protocol/iop-protocol.hdp
/home/cgay/dylan/workspaces/od/opendylan/sources/corba/orb/poa/../iop-protocol/iop-protocol.hdp
/home/cgay/dylan/workspaces/od/opendylan/sources/corba/orb/connections/../iop-protocol/iop-protocol.hdp
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.