-
Notifications
You must be signed in to change notification settings - Fork 206
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
Integration with clib #17
Comments
Sounds like a great idea! What's the best way to do the integration? |
For now, we'd have to split the ccan repo into individual parts. Each lib would need its own repo and to specify its own In time, support could be added for fetching packages listed within a "main" repository. Something like: Thoughts @jwerle @visionmedia |
I think a script that imports ccan libs into github and tests them would be ideal here. No need to introduce complexity to support ccan. Support for arbitrary remotes with a ccan proxy is another possibility. |
@jb55 A lot of ccan modules make references to other ccan modules in the code.. :( |
This is kind of the same discussions component/component went through when people wanted to support bower packages. It didn't make sense to support every other ecosystem without turning your own into a mudball. The solution was, if you wanted a package from bower/ccan/etc you could simply fork/clone it and add a package.json, fixing any include refs along the way. An import script to do this automatically would be handy as well. |
I agree ! I find this to be annoying as I'd like to be able to use packages from anywhere. It would be nice if we could preserve directory structure if the user wanted. cc @stephenmathieson thoughts ? |
I like the import script idea, but it doesn't solve keeping the repos up-to-date with the upstream repository (e.g. this one). This likely isn't a huge deal, as we're already doing it a few places (linenoise, inih, etc.). |
Stephen Mathieson [email protected] writes:
So, I really like the clib concept. In many ways, CCAN modules are a subset of what clib allows (eg. we Having a way to pull part of a git tree would help (a-la git subtree?). Writing a ccantool --clib which spits out the package.json would be Here's a horrible shell script which demonstrates the idea (is there a #! /bin/sh -e eg /home/rusty/devel/cvs/ccan/ccan/foo/bar => /home/rusty/devel/cvs/ccanfind_ccandir() Simplistic...json_escape() Eg:{"name": "mon","version": "1.1.1","repo": "visionmedia/mon","description": "Simple process monitoring","keywords": ["process", "monitoring", "monitor", "availability"],"license": "MIT","install": "make install"#} if [ $# = 1 ]; then MODDIR="$(pwd)" To get doc_extractPATH="$CCANDIR/tools:$PATH" if [ ! -f _info ]; then CCAN modules can be nested.FULLNAME=$(json_escape "${MODDIR##*ccan/}") echo '{' |
@stephenmathieson any ideas about the solution @rustyrussell proposed? |
@dumblob we created a conversion script here, just need to automate the creation of Github repos: |
I've been working on a similar concept, called clib. Thoughts on working together and possibly allowing ccan modules to be installed with clib(1)?
The text was updated successfully, but these errors were encountered: