[squeak-dev] [Cuis] Cuis - Cross fork compatibility of packages:
A proposal
Juan Vuletich
juan at jvuletich.org
Tue Jan 26 14:45:30 UTC 2010
keith wrote:
>> 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.
Why? All that is needed is to be able to run the same tests on all fork.
That is asking a lot less than the SUnit package is exactly the same...
Se Julian's recent message about Seaside and Grease. It even works
across Smalltalk dialects.
>
> 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).
Why? This has nothing to do with how code is loaded into each
environment. Package developers might choose between ChangeSets,
Monticello, or possibly other options.
>
> However, most forks imho are keeping all of their libraries too close
> to their chests.
This initiative (actually Grease) allows each fork to do exactly that,
while having guaranteed compatibility. It is the best of both worlds.
>
> 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.
Those are package specific problems. I suggest getting in touch with
Monticello developers to merge your changes.
>
> ...
>
> Correct me if I am wrong, but in my thinking if SUnit is forked, your
> vision is pretty doomed.
As I said above, I see no reason for this.
> ...
Cheers,
Juan Vuletich
More information about the Squeak-dev
mailing list
|