[squeak-dev] [Cuis] Cuis - Cross fork compatibility of packages: A proposal

keith keith_hodges at yahoo.co.uk
Tue Jan 26 02:06:14 UTC 2010


> Hi Folks,
>
> (reposted, in the hope of not being ignored)
>
> Package developers want their work to run on various Squeak versions  
> and variants, without needing rewrite. Same for app developers.
>
> Base image builders want to be free of the need to provide backwards  
> compatibility.
>
> This is what I suggest: A package assumes it can use a set of apis  
> of the Squeak (/Pharo/Cuis/Etoys/Tweak/Cobalt/etc) environment.  
> Those assumptions should be made explicit, in the form of tests. So,  
> for example, for collections, some package developer might require  
> the "Common Collection API tests" to pass. Then, if his package  
> fails to run, let's say in Cuis, he would run the tests for the apis  
> he needs. If some test fails, he could say "Cuis developers, you're  
> not supporting api XXX", end expect them to fix the issue. But if no  
> test fails, he needs to either modify his code so it doesn't use not- 
> standarized apis, or he could negotiate with (all) base image  
> developers the addition of a new api or use case to the test suite  
> and the base images.

Agreed wholeheartedly.

For this vision to have a chance, absolutely one thing is 100%  
essential. SUnit must be common, between forks, and there must be some  
way of flagging known exceptions for different target images. This is  
something I attempted to add to SUnit in August 2006, in eagre  
anticipation.

The second essential thing is for the package loading tools to also be  
in common. That means Monticello (in my book, though probably not in  
yours).

However, most forks imho are keeping all of their libraries too close  
to their chests.

All efforts to change this, to move obvious loadable libraries like  
SUnit, and MC out to be externally managed, have up to now failed. The  
weakness of my attempts so far has been in the testing side of things.  
(Matthew Fulmer is worth is weight in gold on that one)

However Monticello is a complicated beast, I may have made 400 more  
commits, merging 3 forks, but one or two bugs is all it takes to  
reject the entire refactoring of the repositories code, the improved  
more uniform ui implementation, the password manager, the dual change  
sorter, the orphanage for out of order loading, public package info  
properties for package managers, scripting of commits, memory analysis  
per package, the atomic loader, cleanUp code, improved version  
numbering, integrated Configurations, separated tests, default  
packageinfo package types etc etc etc.

I always needed others who are more rigourous to join in and help, but  
so far the vision hasn't caught.

I now think it is going to fall to the forks for whom the libraries  
are already genuinely optional, to pioneer this process. i.e. Cuis.

> Building these suites is quite some work, mostly to be done by  
> package developers.

As I said, if you try to treat what is perceived as an integral  
library as an external package, to be maintained by a package  
developer, with the API maintained by "actual conversation" between  
the fork-leaders and the package maintainers. The fork controllers  
wont have any of it, they forked for the purposes of retaining  
control, and wild horses wont shift them.

I tried, I asked, I begged, I cried, I explained, and I ranted, in the  
belief that it was now or never. Up until Pharo, all "forks" were  
basically differing applications on the same evolving kernel. With  
Pharo this is different, they are moving the Kernel in a different  
direction on purpose, however for some reason they believe that  
forking SUnit, an obviously loadable package, is necessary too!

Correct me if I am wrong, but in my thinking if SUnit is forked, your  
vision is pretty doomed.

SUnit is forked.

> But it can easily point out responsibilities and duties. It frees  
> package developers of needing to have a deep knowledge of various  
> base images. And it frees base image developers from needing to know  
> details about an unbounded set of external packages. Besides, it  
> puts popular packages that everybody wants to support on equal  
> footing with less-known packages. It also lets base image developers  
> say "we support Common APIs xxx, yyy, zzz, etc.".
>
> All what I say about base images could also apply to packages that  
> offer services to other packages: There could also be test suites to  
> specify their services, and allow users to switch versions of the  
> packages they use knowing what to expect.
>
> What do you think?

Like I say, I agree completely, however this is "planning", this is  
"thinking", this is showing "leadership", and defining a conceptual  
"process", with conceptual roles and responsibilities.

However, may I point out we don't need to do that here, we have a  
shared repository you can commit your changes to, its called "trunk".

Keith

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100126/584d6b1b/attachment.htm


More information about the Squeak-dev mailing list