Closed jwerle closed 4 years ago
oopsi apparently i somehow forgot to respond to this, sorry.
so yes, zz has modules and the current structure is a skeleton for an eventual package manager to come.
The current missing puzzle piece is how to solve version conflicts. i.e. A requires B which requires C version 1, but A also requires D which requires C version 2 npm and rust simply pull in all required versions in the tree, but that's not something that fits the idea of zz (usable for embedded).
I'll probably start implementing it by just failing if there's a version conflict. linux distros do this and they're fine. although they're also centrally controlled, so no idea what's going to happen.
if you have any additional comments on how a package manager should look like, let me know
Put a small experiment together using npm
here: that creates symlinks when a module is installed mapping node_modules/ -> modules/
Thanks for the insight. Do you imagine a package manager for zz
centralizing dependency installations on a machine in places like $HOME/.zz/modules
or /usr/lib/share/zz/modules
?
Any ideas about a module registry? We used Github for the clib and bpkg.
The experiment with npm
I shared is obviously opposite to the approach you described. I also tried this with Kotlin/Native some years ago here
centralizing dependency installations on a machine
no. deps are always specific to a project. zz will never manage system packages
Any ideas about a module registry? We used Github for the clib and bpkg.
oh yeah, absolutely. or actually clibs sounds like something we should just straight up integrate with. the low hanging fruit here is ZZ can generate and consume clibs package.json format
The experiment with npm
I'm not sure i understand what this does. zz already generates nodejs modules https://github.com/aep/zz/wiki/using-zz-in-other-ecosystems#nodejs
The experiment allowed me to import a user space ZZ module into another. It doesn't use JavaScript or node, just npm for package management
so we could just use the official npm registry? i mean, thats a pretty cool idea if it works
Yeah it's possible. More tests and examples to come
On Tue, Mar 24, 2020, 10:41 Arvid E. Picciani notifications@github.com wrote:
so we could just use the official npm registry? i mean, thats a pretty cool idea if it works
β You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/aep/zz/issues/34#issuecomment-603278412, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALFFPOTRDPE5MKERJREZB3RJDBAFANCNFSM4LPKHXXQ .
one of the things i really dont apprechiate about nodejs style packaging is that old code rarely compiles. zz is really about catering to professional developers who typically prefer tighter control over their projects.
clib makes more sense to me. it appears to be mostly an index for downloading stuff, but you keep the stuff in your projects repo
One thing that bothers me a bit in practical terms when working with Rust is that the target directory for each repo gets massive. Maybe that's just a Rust thing, since from what I can tell, the output of zz builds (at least in --release
mode now that I know how to use it) is tiny in comparison since it's straight C?
@jwerle how would you recommend to integrate clib?
@aep I don't think clib in its current form will work well for zz modules. clib-install
does not maintain directory structures needed for a ZZ project. I've started tinkering over here with a simple module installer: https://github.com/zx-project
ok no problem, we can get to conveniently import clib later.
what do you think are important things to consider when building a package manager? what are your top learnings from working on clib?
what do you think are important things to consider when building a package manager?
I wish I had more experience to feel fully qualified to answer that question. I think for ZZ's scope, a tool that can initially install and de-dupe ZZ modules that are versioned (semver/tag/etc) makes the most sense as a MVP. Using Github the same way we did with clib should be pretty straightforward.
what are your top learnings from working on clib?
we should've started with pthreads and shared curl contexts because installs can be slow when a lot of dependencies build up. This is currently built in clib@next. We also should have started with clib.json
instead of package.json
as a manifest file because of the NPM/node conflict. We're okay here with ZZ because zz.toml
already exists
i'll start working on this now
@richardanaya i'd apprechiate your input on this thread
see https://github.com/zetzit/zz/pull/55
add this to your zz.toml:
[repos]
myrepo = "git://github.com/you/yourmodules.git"
we can add an official website for discovery later, but this will help people share modules quickly
closing for now
Hi @aep!
I love the project.
Have you thought about how one may install and consume user space ZZ modules? This hints at a package manager, possibly. I see that
zz
will look in a project'smodules/
directory when resolving dependencies.What are your thoughts?