Open CyberShadow opened 1 year ago
github-actions[bot]
commented
1 year ago ✅ PR OK, no changes in deprecations or warnings
Total deprecations: 15
Total warnings: 0
Build statistics:
statistics (-before, +after)
-executable size=5276640 bin/dub
-rough build time=75s
+executable size=5272544 bin/dub
+rough build time=76s
WebFreak001
commented
1 year ago can you add a test for this?
CyberShadow
commented
1 year ago That's tricky, as the thing to test here is that Dub does not try to read this unrelated file / enter this unrelated directory. It does gracefully skip broken symlinks, so aside something like a logging / error-injecting FUSE filesystem I can't think of anything right now.
CyberShadow
commented
1 year ago If I do chmod 000 on a directory, that does cause current Dub to fail, but I don't think that would make for a very good test. For one, it's POSIX-only; for two, that should probably be fixed to skip unreadable directories anyway, in the same way that broken symlinks are.
CyberShadow
commented
1 year ago Added it as I can't think of anything better right now, and I see the tests are POSIX-only anyway.
WebFreak001
commented
1 year ago you still need to put in the .no_build, .no_test, .no_run files so the CI tests don't try to do those.
CyberShadow
commented
1 year ago BTW I'm seeing zero documentation on how to run the test suite. A section in the README, or a test/README.md, would be nice.
WebFreak001
commented
1 year ago here are some projects which rely on .. in globbing, to test if they still work properly:
for source paths:
for source files:
for import paths:
it seems that this is even intended documented behavior, although I don't get what it has to do with git submodules.
I think it would have made more sense that importPaths ".." would only scan its own directory, since it's used to make the DUB package name being used as module package name for all files within (and no source directory needed)
WebFreak001
commented
1 year ago I think what we should do for import paths: (and C import paths, since they are the same thing for some compilers)
".." the only allowed import path that can escape the project root (means it will just pass that to the compiler, but only grep within the current project)
packagename/version/packagename/{project files}, so the parent folder is known to only contain a single folder with D/C files, with a known and fixed namethis way we also have proper semantics for importPaths ".." that users can utilize effectively and with solid guarantees.
CyberShadow
commented
1 year ago for source paths:
* https://github.com/andrey-zherikov/argparse/blob/6fca01c219828b8223b64e1c7899e1cd7c2b2eb9/examples/completion/single_main/app/dub.json#L5
Hmm, I think the intent there is to put Dub-related files in their own directory? I'm not sure what to do here. Is it even possible to publish this to the Dub registry? But even if not, importPaths "../source" would be valid and meaningful for a library which did this and then used locally with dub add-local.
for source files:
* https://github.com/dokutoku/dxlib-d/blob/2e539d4dfda5804fed1a4a0c29957e7dd96f7819/examples/windows/example/dub.json#L20
Makes sense.
for import paths:
* https://github.com/dlang-community/gitcompatibledubpackage/blob/master/dub.sdl#L22-L25
Ah, that one's mine! Looks like I made this a long time ago to illustrate the same problem.
I think what we should do for import paths: (and C import paths, since they are the same thing for some compilers)
Sounds like a plan... though, it does bother me that we don't have a solid and defensible mechanism which would be used to decide which sets of paths are filtered, and how.
Perhaps this is the wrong approach entirely, and we need something like a moduleRoot declaration. So then, moduleRoot "foo" would tell Dub that a bar.d in the project root corresponds to the module foo.bar, and that the directory containing the project should be named foo, and that its parent directory should be added to the import (-I) paths; or even use the -mv compiler feature to make things align if the directory structure doesn't allow it.
WebFreak001
commented
1 year ago Perhaps this is the wrong approach entirely, and we need something like a moduleRoot declaration. So then, moduleRoot "foo" would tell Dub that a bar.d in the project root corresponds to the module foo.bar, and that the directory containing the project should be named foo, and that its parent directory should be added to the import (-I) paths; or even use the -mv compiler feature to make things align if the directory structure doesn't allow it.
I think -mv should be avoided by the user, I more see it as something that tools could use to do special purpose stuff, such as sharing the same dependency with multiple versions in a build. Mapping module structure to the file/folder structure makes it easier to reason about what happens and explain to people how things work.
moduleRoot could be one thing how this could be done, but I think keeping "name" for it already makes sense, although it breaks when users use - in their package name.
Do you have a requirement / use-case why you need to control the parent folder/current folder relationship?
CyberShadow
commented
1 year ago I think
-mvshould be avoided by the user, I more see it as something that tools could use to do special purpose stuff
Yeah sorry, I meant that Dub could use -mv under the hood to implement moduleRoot.
moduleRoot could be one thing how this could be done, but I think keeping "name" for it already makes sense, although it breaks when users use
-in their package name.
Well the Dub package name doesn't always correspond to the module name, and special symbols aren't the only case. Probably the most prominent example I'm aware of is arsd_official.
Do you have a requirement / use-case why you need to control the parent folder/current folder relationship?
It's ae and projects structured like it (see that gitcompatibledubpackage project above). The structure allows using both Dub and Git submodules for dependency versioning.
Of course it would be nice to understand and fix the problem as generally as possible. For example, what about something like a package called lib_foo in a directory foo which holds modules in the lib.foo namespace, a package called lib_bar in a directory bar which holds modules in the lib.bar namespace... then, the equivalent importPath would be "../..".
What do you think?