Skip to content
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

deft new library: better directory organization #9

Open
cgay opened this issue Jun 14, 2023 · 1 comment
Open

deft new library: better directory organization #9

cgay opened this issue Jun 14, 2023 · 1 comment

Comments

@cgay
Copy link
Member

cgay commented Jun 14, 2023

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.

@cgay cgay transferred this issue from dylan-lang/dylan-tool Apr 21, 2024
@cgay cgay changed the title new library: Put dylan sources in subdirectory deft new library: better directory organization May 23, 2024
@cgay
Copy link
Member Author

cgay commented May 23, 2024

Here's a proposed new directory organization. einstrauch mentioned in the Dylan chat that they were a little confused by the "-app" naming at first. I've never liked it myself, and it's one of those things that new users will hit right away.

https://gist.github.com/cgay/86a412f866cf1267d962c0174915ad1e suggests a potential new layout. Essentially this:

./dylan-package.json
./app/foo.lid
./app/foo.dylan
./app/library.dylan
./lib/foo-lib.dylan
./lib/foo-lib.lid
./lib/tests/foo-lib-test-suite.lid
./lib/tests/foo-lib-test-suite.dylan
./lib/tests/library.dylan
./lib/library.dylan
./README.rst

With app and lib subdirectories I don't think src is necessary (and it's not like people can't change it if they want; this is just a default).

A separate directory per library is kind of nice. library.dylan is always the library definition and the organization is clear.

The obvious down side is that we now have foo-lib, but as einstrauch pointed out, users are kind of used to this naming convention.

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

No branches or pull requests

1 participant