Cross fork compatibility of packages: A proposal

> Hi Folks,
>
> 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.
>
> Building these suites is quite some work, mostly to be done by package
> developers. 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?
>
> Cheers,
> Juan Vuletich
>
>

> This is kind of what Seaside's Grease platform is starting to provide,
> so obviously I think it's a good approach. Grease documents "standard"
> APIs that we expect on all platforms via unit tests. Each platform is
> then required to ensure the tests pass, either by fixing their base
> image, or by adding extensions to their Grease package.
>
> If Seaside doesn't work and all the Grease tests pass, either we need
> to change Seaside, or add a test to Grease. We've now begun using
> Grease as the basis for Pier, Magritte, and MC2, so the hope is that
> it might become generally useful to other projects that want to write
> code that runs across platforms (we're not just talking Squeak forks
> here though; this includes VW, VASt, GemStone, Gnu, etc). That's a
> lofty goal, though, and we're taking a pragmatic, step by step
> approach.
>
> Julian
>
> On Sun, Jan 24, 2010 at 10:07 PM, Juan Vuletich <[hidden email]> wrote:
>  
>> Hi Folks,
>>
>> 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.
>>
>> Building these suites is quite some work, mostly to be done by package
>> developers. 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?
>>
>> Cheers,
>> Juan Vuletich
>>
>>
>>    

> Great! So, it is not a new idea. Let me suggest all the package developers
> to adopt Grease and help develop it! I'll be really happy to give support
> for Grease in Cuis.
>
> Cheers,
> Juan Vuletich
>
> Julian Fitzell wrote:
>>
>> This is kind of what Seaside's Grease platform is starting to provide,
>> so obviously I think it's a good approach. Grease documents "standard"
>> APIs that we expect on all platforms via unit tests. Each platform is
>> then required to ensure the tests pass, either by fixing their base
>> image, or by adding extensions to their Grease package.
>>
>> If Seaside doesn't work and all the Grease tests pass, either we need
>> to change Seaside, or add a test to Grease. We've now begun using
>> Grease as the basis for Pier, Magritte, and MC2, so the hope is that
>> it might become generally useful to other projects that want to write
>> code that runs across platforms (we're not just talking Squeak forks
>> here though; this includes VW, VASt, GemStone, Gnu, etc). That's a
>> lofty goal, though, and we're taking a pragmatic, step by step
>> approach.
>>
>> Julian
>>
>> On Sun, Jan 24, 2010 at 10:07 PM, Juan Vuletich <[hidden email]>
>> wrote:
>>
>>>
>>> Hi Folks,
>>>
>>> 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.
>>>
>>> Building these suites is quite some work, mostly to be done by package
>>> developers. 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?
>>>
>>> Cheers,
>>> Juan Vuletich
>>>
>>>
>>>
>
>
>

> Heh, I don't know if all developers will find it appropriate for their
> needs yet; it's obviously providing primarily the stuff that Seaside
> needs but we're certainly hopeful it will become helpful to others
> over time. I'm going through an exercise with all the platforms at the
> moment to extend the defined protocol a bit. Getting agreement on
> stuff is a slow process... :)
>
> I've said a couple of times I need to write a blog post about Grease's
> goals... I'll try to do that this week.
>
> Currently Squeak is pretty much using the Grease implementation
> defined for Pharo, though that may become less practical over time.
> You could try loading Grease-Core, Grease-Pharo-Core, and
> Grease-Tests-Core into Cuis and see how much passes. :)
>
> Julian
>
> On Tue, Jan 26, 2010 at 6:44 AM, Juan Vuletich <[hidden email]> wrote:
>> Great! So, it is not a new idea. Let me suggest all the package developers
>> to adopt Grease and help develop it! I'll be really happy to give support
>> for Grease in Cuis.
>>
>> Cheers,
>> Juan Vuletich
>>
>> Julian Fitzell wrote:
>>>
>>> This is kind of what Seaside's Grease platform is starting to provide,
>>> so obviously I think it's a good approach. Grease documents "standard"
>>> APIs that we expect on all platforms via unit tests. Each platform is
>>> then required to ensure the tests pass, either by fixing their base
>>> image, or by adding extensions to their Grease package.
>>>
>>> If Seaside doesn't work and all the Grease tests pass, either we need
>>> to change Seaside, or add a test to Grease. We've now begun using
>>> Grease as the basis for Pier, Magritte, and MC2, so the hope is that
>>> it might become generally useful to other projects that want to write
>>> code that runs across platforms (we're not just talking Squeak forks
>>> here though; this includes VW, VASt, GemStone, Gnu, etc). That's a
>>> lofty goal, though, and we're taking a pragmatic, step by step
>>> approach.
>>>
>>> Julian
>>>
>>> On Sun, Jan 24, 2010 at 10:07 PM, Juan Vuletich <[hidden email]>
>>> wrote:
>>>
>>>>
>>>> Hi Folks,
>>>>
>>>> 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.
>>>>
>>>> Building these suites is quite some work, mostly to be done by package
>>>> developers. 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?
>>>>
>>>> Cheers,
>>>> Juan Vuletich
>>>>
>>>>
>>>>
>>
>>
>>
>
>

> It's green in latest trunk.
>
> I have some suggestions like
>
> convertToSmalltalkNewlines: aString
>    ^aString withSqueakLineEnding
>
> It works in Pharo1.0 and should be much faster in Pharo1.1.
> It also work in trunk.
> Did not check Cuis, but the method is stamped from 2004, so I presume
> it should be compatible backward enough.
>
> Where should I post such remarks?
>
> Nicolas
>
> 2010/1/26 Julian Fitzell <[hidden email]>:
>> Heh, I don't know if all developers will find it appropriate for their
>> needs yet; it's obviously providing primarily the stuff that Seaside
>> needs but we're certainly hopeful it will become helpful to others
>> over time. I'm going through an exercise with all the platforms at the
>> moment to extend the defined protocol a bit. Getting agreement on
>> stuff is a slow process... :)
>>
>> I've said a couple of times I need to write a blog post about Grease's
>> goals... I'll try to do that this week.
>>
>> Currently Squeak is pretty much using the Grease implementation
>> defined for Pharo, though that may become less practical over time.
>> You could try loading Grease-Core, Grease-Pharo-Core, and
>> Grease-Tests-Core into Cuis and see how much passes. :)
>>
>> Julian
>>
>> On Tue, Jan 26, 2010 at 6:44 AM, Juan Vuletich <[hidden email]> wrote:
>>> Great! So, it is not a new idea. Let me suggest all the package developers
>>> to adopt Grease and help develop it! I'll be really happy to give support
>>> for Grease in Cuis.
>>>
>>> Cheers,
>>> Juan Vuletich
>>>
>>> Julian Fitzell wrote:
>>>>
>>>> This is kind of what Seaside's Grease platform is starting to provide,
>>>> so obviously I think it's a good approach. Grease documents "standard"
>>>> APIs that we expect on all platforms via unit tests. Each platform is
>>>> then required to ensure the tests pass, either by fixing their base
>>>> image, or by adding extensions to their Grease package.
>>>>
>>>> If Seaside doesn't work and all the Grease tests pass, either we need
>>>> to change Seaside, or add a test to Grease. We've now begun using
>>>> Grease as the basis for Pier, Magritte, and MC2, so the hope is that
>>>> it might become generally useful to other projects that want to write
>>>> code that runs across platforms (we're not just talking Squeak forks
>>>> here though; this includes VW, VASt, GemStone, Gnu, etc). That's a
>>>> lofty goal, though, and we're taking a pragmatic, step by step
>>>> approach.
>>>>
>>>> Julian
>>>>
>>>> On Sun, Jan 24, 2010 at 10:07 PM, Juan Vuletich <[hidden email]>
>>>> wrote:
>>>>
>>>>>
>>>>> Hi Folks,
>>>>>
>>>>> 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.
>>>>>
>>>>> Building these suites is quite some work, mostly to be done by package
>>>>> developers. 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?
>>>>>
>>>>> Cheers,
>>>>> Juan Vuletich
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>
>>
>
>