-
Notifications
You must be signed in to change notification settings - Fork 92
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
Package management #1903
base: master
Are you sure you want to change the base?
Package management #1903
Conversation
I have already shared this on the Discord with @yannham, hope its fine to bring it in this discussion here also. This one is Rust based, and self aware about many aspects, that need to be explicitly typed in other package management solutions. I found it very easy to package, as its files need very little input. |
Thanks for sharing this! It will be cool if we can piggy-back on their registry instead of building our own. But even if we can, there are definitely some package-management parts that we'll have to build ourselves (like having the interpreter understand imports from packages vs imports from the local filesystem). I'm going to focus on this part first, and look into the registry aspect later. I did look into their docs a bit and it seems to be focused on running services. Do you know if they have a mode where you can just say "give me a bunch of files (including transitive deps) and put them in a well-known place"? |
I really recommend that you ask these questions the Habitat folks directly. I did use it a couple of years ago, and dont remember most. |
The macOS build is failing because of this, which no one seems to know how to solve... |
Bencher Report
Click to view all benchmark results
|
2e928b2
to
2121742
Compare
This is a hacky prototype of package management. I'm pushing it here not because it's useful yet, but to see if it's a direction we want to pursue.
First of all, I think we had discussed trying to piggy-back off npm (or other registries), but their terms (specifically, point 4) seem to prohibit it. So this prototype ditches registries altogether, allowing only git deps and path deps. In particular, we don't have any version resolution yet.
Anyway, what this PR allows is imports like
import "file.ncl"@my-org/my-package
. For such imports to work, you need to specify a manifest file that lists the "my-org/my-package" package. The manifest files are not auto-detected; you need to explicitly provide them with the--manifest-file
option. So for example, given these files:if you run
nickel eval --manifest-file foo/package.ncl foo/main.ncl
it will print "hi0.1.0".The current prototype allows for different copies of the same package, and it properly keeps them separate: if you depend on "example/foo" from one location and one of your dependencies depends on "example/foo" from some other location,
import "bar.ncl"@example/foo
will be interpreted according to whether it appears in your code or your dependency's code.