[openspending-dev] openspending and openspendingjs as separate repositories

Wed Aug 8 12:28:22 UTC 2012

Hey all,

On Tue, Aug 7, 2012 at 9:03 PM, Vitor Baptista <vitor at vitorbaptista.com> wrote:
> Hi Nick,
>
> 2012/8/7 Nick Stenning <nickstenning at gmail.com>
>>
>> a) Having JS as a separate repository encourages you to loosely couple the
>> JS and the OpenSpending backend. This is a good thing. Modular client
>> applications on top of well designed REST APIs is the way the web is going.
>
>
> That's a very good point. This is valid for the widgets in openspendingjs,
> but there's still glue code, and code that's not worthy to be separated
> (like search). At least this part should be in the openspending repository.
>
> This would make more sense if the entire openspending.org app would simply
> use the backend through an API, but to separate it is a huge effort, that
> probably isn't worthy now.

But we've been moving this way: the OpenSpending frontend used to call
the model in all kinds of places, this has been reduced a lot over the
past few months and I'd like to push it down further (i.e. no calls to
the Aggregator interface from anything but the API controller). I
don't think we should invest a lot of energy into translating stuff
like the views system or the editor into JS (there's just no gain),
but we should make sure that new stuff prefers APIs over Templates.

>> b) it's also helpful for people like Gregor, who might know their stuff
>> when it comes to JS, but don't want to be faced with the full complexity of
>> the OS codebase.
>
>
> I understand that, for this use case, it's better to have a separate
> repository. But, even if both are in only one repo, if you don't want to be
> bothered by the backend, you can go to javascript's folder and develop
> there.
>
>>
>> So. I'm in favour of keeping the the repo separate, but I recognise the
>> concerns:
>>
>> 1) that concrete versions of OSJS are no longer tied to concrete versions
>> of OS
>>
>> 2) that developing across two repositories is a pain
>>
>> And guess what, there's a solution that addresses both of these issues and
>> isn't git submodules!
>>
>> Git subtree is now distributed with mainline git (in the contrib
>> directory) and allows you to include one repo within another as if it were
>> just another checkout. See the okfn wordpress repository for an example of
>> how it's used to pull in the okfn theme from another repo.
>>
>> Here's the (out-of-date) original repo for git-subtree:
>>
>>   https://github.com/apenwarr/git-subtree/
>>
>> And a couple of blog posts describing its use:
>>
>>
>> http://psionides.eu/2010/02/04/sharing-code-between-projects-with-git-subtree/
>>   http://apenwarr.ca/log/?m=200904#30
>
>
> That seems cool, thanks for the link. I felt it was kinda complex, but it
> might be an option.
>
> Maybe the best option is to move whatever is coupled to openspending to the
> openspending repo, and tie the openspendingjs with git-subtree or something
> similar? This feels too complex now, but maybe we can work to simplify it.

I really wouldn't bother figuring out which parts of the OS JavaScript
are OS-specific - that's just a complete waste of time and even if you
work it out the result will be a gigantic JS dependency mess.

In general, I don't have strong feelings about where the JS stuff
should live. My slight preference is to keep this separate and to use
feature branches for incompatible work - the point is that OS doesn't
actually have versions and both pieces should be deployable. If it
really seems important to you though, Vitor, then you should merge it.

Cheers,

- Friedrich