package manager

[jwerle]

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's modules/ directory when resolving dependencies.

What are your thoughts?

[aep]

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

[jwerle]

Put a small experiment together using npm here: that creates symlinks when a module is installed mapping node_modules/ -> modules/

[jwerle]

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

[aep]

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

[jwerle]

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

[aep]

so we could just use the official npm registry?
i mean, thats a pretty cool idea if it works

[jwerle]

Yeah it's possible. More tests and examples to come

…

On Tue, Mar 24, 2020, 10:41 Arvid E. Picciani ***@***.***> 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 <#34 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALFFPOTRDPE5MKERJREZB3RJDBAFANCNFSM4LPKHXXQ> .

[aep]

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

[DestyNova]

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?

[aep]

@jwerle how would you recommend to integrate clib?

[jwerle]

@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

[aep]

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?

[jwerle]

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

[aep]

i'll start working on this now

@richardanaya i'd apprechiate your input on this thread

[aep]

see #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

[jwerle]

closing for now