search

codi-sh / codi.sh

0 stars 0 forks source link

Link in projects #6

Open cadorn opened 9 years ago

cadorn commented 9 years ago

Please give me a list of projects you want to host in this system broken up into one level of groups.

i.e. all your Q projects and sub-projects and any utility libs etc... any code you typically hack on while working on your libs that you want to host on this system and have source-linked.

Once I configure these and port a tool to boot.origin these projects can be installed on demand including their dependencies and have everything linked. This will ensure that root install has minimal dependencies and is primarily meta-data and everything else gets loaded in as needed.

50+ services is fine. Use . to delimit group segments. Group names have no meaning other than for visual scanning. Project names must be unique across system. Project names do NOT need to be the same as github repository name nor name in package.json.

The naming of the codebase is important as it grows and is hard to rename later as people get used to it. Keep it future-proof but don't over-think. If you are stuck remember that the names need to make sense within this system primarily unless you want to develop a naming scheme you can transfer across systems. The same projects can be mapped in many systems so the projects mapped are truly the ones needed for this system only.

Here is the list from the root instance I am currently using for inspiration: https://gist.github.com/cadorn/6a797b599ee313364715

I used numbers to prefix some groups to indicate the different layers of the system. Thats optional. I'll review your list and we can discuss before I implement.

cadorn commented 9 years ago

A few groups I would like to setup:

I use reverse hostname dot notation for packages concerning assets distributed outside of the system. This ensures when they are used they will never collide in the global system namespace.

Packages/projects starting with proto and play are system local packages and intended for use within the system and the systems immediate user community only. They are NOT intended for others to build projects off but are educational only and allow us to write markdown and link to frozen code (through system-wide tests on commit integration) that will continue to work down the road as the prototypes double as demanding users of the primitive APIs we are trying to refine. This is critical. It allows us to iterate on advanced features and concepts while showing others and blogging about it but does not put us in a position where we have to support the APIs as users know they are currently unsupported. They can collaborate if they have the chops but don't expect help.

Feedback on naming welcome. I just need to incorporate the above mentioned aspects.