Ph0enixKM
Implemented AMBER_PATH for import lookup
This implements #668 and opens up possibilities for simpler package managers, as they could export a set of standard paths.
Now, if AMBER_PATH is set to /usr/lib/amber:$HOME/.local/lib/amber for instance, in addition to the current directory, import directives will look in those directories as well.
This is a draft/proof-of-concept and there's a couple things to do:
- [ ]Â Exclude paths that start with
.or..from environment lookup - [ ] Define a default set of
AMBER_PATHpaths - [ ] Ideally move the stdlib out into one of these paths (how do other cargo projects distribute installable resources???)
i dont know if this is the right way forward. wouldn't it cause a lot of confusion and inconsistency between different package managers? since there is no rigidly defined place where should they place their packages
i dont know if this is the right way forward. wouldn't it cause a lot of confusion and inconsistency between different package managers? since there is no rigidly defined place where should they place their packages
That is how every compiler does it under the hood. There are default values (which I intend to add for Amber as well as soon as I can make sure we can ship stdlib in one of them) but leaving this path system open allows for integrating with other buildsystems like Meson, Autoconf or Nix, where dependencies may not be in standard paths for technical reasons.
In the future adding a default package manager to Amber isn't incompatible with this option, just wish to keep modularity in mind -- amber would be a git-like modular CLI which could call amberc, a pure and simple compiler.
Another reason to allow flexible paths is virtual environments. The only way to prevent dependency collision is to let users specify where dependencies are on a per-project basis.
Just as Python developers rarely think about PYTHONPATH, ideally you won't need to know about AMBER_PATH. Your build tool just sets it for you.
Another reason to allow flexible paths is virtual environments. The only way to prevent dependency collision is to let users specify where dependencies are on a per-project basis.
they are obviously scoped per directory as specified in #668:
image
which is a predictable and rigidly defined set of paths, while still allowing for flexibility.
also i invite you to continue this conversation in #668, since pull requests are for implementing things outlined in issues, not for discussing the idea itself.
I'd like to mention that LSP on which @KrosFire is working (which btw works with couple of bugs that need to be fixed to work properly) will require this PR
I'd like to mention that LSP on which @KrosFire is working (which btw works with couple of bugs that need to be fixed to work properly) will require this PR
not this PR specifically. it will require for stdlib to be accessible via the filesystem, which is currently implemented in about 4 different experimental ways