

Peru – A tool for including other people's code in your projects - oconnor663
https://github.com/buildinspace/peru

======
flohofwoe
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](https://github.com/floooh/oryol)

~~~
oconnor663
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](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.)

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

------
whitten
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.

------
jasonlaster11
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...

~~~
oconnor663
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.

------
smrtinsert
As a Peruvian I'm tickled by this since our cuisine is known for importing
from others.

~~~
oconnor663
If we ever get a mascot, I really want it to be a vicuña :)

