8 comments

[ 3.2 ms ] story [ 28.9 ms ] thread
Peru follows the Unix paradigm by doing only one thing, and doing it well. It fetches code from multiple sources and puts it into a directory.
Thanks! This is a cool concept. It's interesting in that it helps pull in projects in a way that seems similar to package managers like npm, bower, bundler...
Yep, that's definitely one of the use cases we're aiming for. Upside: You can use the same tool for multiple languages, and it's better than some at specifying exact versions. Downside: It's not clear how we'll want to handle transitive dependencies. It will probably end up working like git submodules, where when A and B both depend on C, you end up with two copies of C. Let me know if you have thoughts.
As a Peruvian I'm tickled by this since our cuisine is known for importing from others.
If we ever get a mascot, I really want it to be a vicuña :)
This looks extremely interesting to me for the following reason: End of last year I started to write a new C++ 3D engine from scratch. It consists of a flat soup of modules, each compiled to a static library. Modules depend on other modules. For an app, pick and choose the modules you need, dependencies are resolved automatically in the build system, and everything is linked together into one exe. For extensibility and 'decentralisation of ownership', it should be possible to setup modules in separate git repositories, and it should be possible that modules can depend on modules in other git repositories. At the same time, external modules should come as full git repos, it should be possible to work on them and commit/push changes. I looked at git submodules, git subtrees, and Google's git-repo, and they're not quite the right thing. In the end I postponed the idea until I either find a better solution, or start writing my own 'external module manager', peru could just be the right solution.

PS: github link: https://github.com/floooh/oryol

Maybe this is hypocritical, but I actually tend to advocate for keeping things in one big repo, when you have that option :) (http://programmers.stackexchange.com/a/236567) I don't think anything beats having all you need in one git log. But if you want external projects to pull down your code and build against it, that's exactly what peru is designed to do.

I mentioned this in another comment, but one of the things we haven't nailed down yet is transitive dependencies: A depends on B which depends on C, etc. If you start playing with peru, I'd love to get feedback on how you think that should work. (The most obvious way would be like git submodules, but I'm not sure how we want to handle multiple copies of the same dependency.)

Hmm yes the 'decentralized' version history would be a problem, true.