Currently, using SourceCred requires either using our docker container, or building it from scratch. It would be convenient for many users if they could simply npm install sourcecred. We should make it happen.
Benefits:
External users will have a much easier time adopting SourceCred.
Implementation plan:
Wait for the instance system so that hypothetical npm users actually have a sensible API
Publish SourceCred on NPM (may involve build yak shaving?)
Actually would like to propose this is split into a few components.
The instance system is part of it.
I would make the “root” sourcecred package something you can reasonably install as a global package. So you can run CLI commands with it.
It would be a minimal package trying to be stable and slow to need upgrades.
Then each instance can have more concrete implementations for this CLI. For example using a @sourcecred/cli package.
That hints at splitting sourcecred into lots of neat packages. But that’s a lot of work for a first implementation. So I would suggest:
sourcecred the minimal proxy CLI.
@sourcecred/cli modern CLI implementation.
@sourcecred/sourcecred the “monolith” style core having mostly the same structure as the same name github repo.
This would set us up nicely for splitting off packages in the future.
I like this suggestion. I’d also really like to make it possible to depend on e.g. the Graph class and the TimelineCred class from outside the codebase. This would let us build much more powerful observable notebooks for tweaking and experimenting with SourceCred. Sounds like we could export this from the @sourcecred/sourcecred package to start.
Do you think we should factor this initiative into sub-initiatives for these different pieces, so we can scope the work more effectively?