a process to maintain non core package

> Hi
>
> in the future I would like to have a process like that to maintain  
> package like sound (or morphic extras) or any package that are not  
> core else we will not be able to maintain them or to apply package  
> wide changes.
>
> - we mark the packages that are not in the image but that we want to  
> maintain
> - at integration step we
> load all the external packages
> - integrate
> - publish in different repos
>
> Else I bet that we will not be able to maintain the non core packages.
>
> Stef
>  

> Stéphane Ducasse wrote:
>> Hi
>>
>> in the future I would like to have a process like that to maintain
>> package like sound (or morphic extras) or any package that are not
>> core else we will not be able to maintain them or to apply package
>> wide changes.
>>
>> - we mark the packages that are not in the image but that we want to
>> maintain
>> - at integration step we
>> load all the external packages
>> - integrate
>> - publish in different repos
>>
>> Else I bet that we will not be able to maintain the non core  
>> packages.
>>
>> Stef
>>
> In PackageInfo/MC1.5 packages keep knowledge of where they were loaded
> from in order to support this scenario
>
> Keith
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Hi
>
> in the future I would like to have a process like that to maintain
> package like sound (or morphic extras) or any package that are not
> core else we will not be able to maintain them or to apply package
> wide changes.
>
> - we mark the packages that are not in the image but that we want to
> maintain
> - at integration step we
> load all the external packages
> - integrate
> - publish in different repos
>
> Else I bet that we will not be able to maintain the non core packages.
>
> Stef
>
> PS: I'm integrating
>
> Issue 1051: Cuis 0053-ensure-close.1.cs
> and some changes touched sound so this is good experiment.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> - There should be a responsible maintainer for each package
> - For each package there should be a known way to discuss and report
> problems
> - A gate keeper includes and removes packages from the set depending
> on their status
>
> This limits the set of included packages (at least initially) but
> would increase the quality and hence the user experience.
>
> Maybe there could be two sets, a stable and an unstable set. New
> packages would first go to the unstable set and then move up to the
> stable set after a while.

>
> Cheers,
> Adrian
>
> On Aug 8, 2009, at 12:31 , Stéphane Ducasse wrote:
>
>> Hi
>>
>> in the future I would like to have a process like that to maintain
>> package like sound (or morphic extras) or any package that are not
>> core else we will not be able to maintain them or to apply package
>> wide changes.
>>
>> - we mark the packages that are not in the image but that we want to
>> maintain
>> - at integration step we
>> load all the external packages
>> - integrate
>> - publish in different repos
>>
>> Else I bet that we will not be able to maintain the non core  
>> packages.
>>
>> Stef
>>
>> PS: I'm integrating
>>
>> Issue 1051: Cuis 0053-ensure-close.1.cs
>> and some changes touched sound so this is good experiment.
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>
> On Aug 9, 2009, at 2:26 PM, Adrian Lienhard wrote:
>
>> Hi,
>>
>> I really think we need a package management system and a process to
>> maintain it.
>>
>> The goal is that loading and using non-core packages "just
>> works" (unlike for instance SqueakMap, where loading more often fails
>> than succeeds because there are a lot of obsolete packages and a
>> dependency mechanism is missing).
>
> Yeap!
>
>> - There should be a responsible maintainer for each package
>> - For each package there should be a known way to discuss and report
>> problems
>> - A gate keeper includes and removes packages from the set depending
>> on their status
>>
>> This limits the set of included packages (at least initially) but
>> would increase the quality and hence the user experience.
>>
>> Maybe there could be two sets, a stable and an unstable set. New
>> packages would first go to the unstable set and then move up to the
>> stable set after a while.
>
> Yes but if we take for example sound. When I integrate a fix from
> Cuis I do not want to get
>
>> An automated build process could load packages into new builds and
>> report the result of the tests.
>
> Yes!
>
>> The package management system does not need to be very sophisticated,
>> but it should manage dependencies and have a simple GUI (to search for
>> packages and see what is already loaded).
>
> Yes.
> We should start incrementally fixing that.
> I should look at Metacello and MC1.5 when I get more time.
>
> Stef
>
>>
>> Cheers,
>> Adrian
>>
>> On Aug 8, 2009, at 12:31 , Stéphane Ducasse wrote:
>>
>>> Hi
>>>
>>> in the future I would like to have a process like that to maintain
>>> package like sound (or morphic extras) or any package that are not
>>> core else we will not be able to maintain them or to apply package
>>> wide changes.
>>>
>>> - we mark the packages that are not in the image but that we want to
>>> maintain
>>> - at integration step we
>>>      load all the external packages
>>> - integrate
>>> - publish in different repos
>>>
>>> Else I bet that we will not be able to maintain the non core
>>> packages.
>>>
>>> Stef
>>>
>>> PS: I'm integrating
>>>
>>> Issue 1051: Cuis 0053-ensure-close.1.cs
>>> and some changes touched sound so this is good experiment.
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> Hi,
>
> I really think we need a package management system and a process to  
> maintain it.
>
> The goal is that loading and using non-core packages "just  
> works" (unlike for instance SqueakMap, where loading more often fails  
> than succeeds because there are a lot of obsolete packages and a  
> dependency mechanism is missing).
>
> - There should be a responsible maintainer for each package
> - For each package there should be a known way to discuss and report  
> problems
> - A gate keeper includes and removes packages from the set depending  
> on their status
>
> This limits the set of included packages (at least initially) but  
> would increase the quality and hence the user experience.
>
> Maybe there could be two sets, a stable and an unstable set. New  
> packages would first go to the unstable set and then move up to the  
> stable set after a while.
>
> An automated build process could load packages into new builds and  
> report the result of the tests.
>
> The package management system does not need to be very sophisticated,  
> but it should manage dependencies and have a simple GUI (to search for  
> packages and see what is already loaded).
>
> Cheers,
> Adrian
>
>  

>   - Package to package dependencies. One can declare required packages
> like the
>     following:
>       'Example-Core-anon.9'
>       'Example-Tests-anon.3' requires: 'Example-Core'
>       'Example-AddOn-anon.1' requires: 'Example-Tests'
>       'Example-UI-anon.1'    requires: { 'OB'. 'Example-AddOn'. }
>     From the above statements, the package load order is derived and used when you
>     load the project:
>       (ExampleProject version: '0.3') load
>     It is also used to determine _which_ packages should be loaded when an
>     expression like the following is executed:
>       (ExampleProject version: '0.3') load: 'Example-AddOn'
>     This statement causes 'Example-Core-anon.9', 'Example-Tests-anon.3',
>     'Example-AddOn-anon.1' to be loaded in order.

> I believe Joseph Pelrine work on one for the "Squeak World Tour" fork.
> http://desk.org:8080/CampSmalltalk/Squeak%20World%20Tour%20Results
>
> From time to time he thinks of bring it up to date, but there is a
> general lack of interest...
> However I can ask him for a spec sheet/objectives for the product and
> see how they match to other
> proposals.
>
> If people are curious about why he would know a bit about package
> management then consider
> http://www.amazon.com/Mastering-Envy-Developer-Joseph-Pelrine/dp/0521666503
>
>
> On 9-Aug-09, at 9:03 AM, Michael Roberts wrote:
>
>> do we have a list of candidate package management systems?
>>
>> cheers,
>>
>> Mike
>>
>
> --
> =
> =
> =
> =
> =
> ======================================================================
> John M. McIntosh <[hidden email]>   Twitter:
> squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://
> www.smalltalkconsulting.com
> =
> =
> =
> =
> =
> ======================================================================
>
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Keith Hodges wrote:
>> Adrian Lienhard wrote:
>>
>>> Hi,
>>>
>>> I really think we need a package management system and a process to
>>> maintain it.
>>>
>>> The goal is that loading and using non-core packages "just
>>> works"
> Same goal as for Sake/Packages, and it works for me.
>
>>> (unlike for instance SqueakMap, where loading more often fails
>>> than succeeds because there are a lot of obsolete packages and a
>>> dependency mechanism is missing).
>>>
>>> - There should be a responsible maintainer for each package
>>>
> Not a realistic proposition. Better to be open to all to maintain on
> behalf of the community.
>>> - For each package there should be a known way to discuss and report
>>> problems
>>>
> That's just arbitrary metadata in the package definition, for more
> general topics we use the [hidden email] mailing list
>>> - A gate keeper includes and removes packages from the set depending
>>> on their status
>>>
> Probably too complicated to be practical.
>>> This limits the set of included packages (at least initially) but
>>> would increase the quality and hence the user experience.
>>>
>>> Maybe there could be two sets, a stable and an unstable set. New
>>>
> Sake/Packages supports a stable and a beta release of each package.
>>> packages would first go to the unstable set and then move up to the
>>> stable set after a while.
>>>
>>> An automated build process could load packages into new builds and
>>> report the result of the tests.
>>>
> Bob does that.
>>> The package management system does not need to be very  
>>> sophisticated,
>>>
> Sake is as simple as possible for defining actions with dependencies.
>>> but it should manage dependencies and have a simple GUI (to search  
>>> for
>>> packages and see what is already loaded).
>>>
> Sake/Packages uses the class browser as is, no extra GUI is required.
>
> Packages provided explore
>
> shows you what is loaded, and this should be merged into
> PackageOrganization.
>
> Keith
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> I have ginsu on my disc since years.
> Ginsu was a good declarative model (now we have MC which plays the  
> same role).
> What we are missing is a package management system. So may be  
> metacello can play this role.
> I think that once we will have cleaner and better modular package we  
> should be able to rely on
> an external build process to integrate and release pharo.
> Right now script loader is a big bag of hack and scripts which were  
> mandatory to deal with dependent
> packages and other dirty things. Also a true atomic loader will help.  
> (I mean true as opposite of Ginsu/MC<1.5
> loader which could not deal with the issue of modifying parts of the  
> system used to load the system).
> So all in all I do not think that there is a need for Ginsu right now.
> Cleaning and making MC better (probably MC2) is the way to go.
> Something I feel that MC1.0 was designed from a UI point of view and  
> is a bit arcane to script.
> Stef
>
>  

> Keith Hodges wrote:
> > Adrian Lienhard wrote:
> >  
> >> Hi,
> >>
> >> I really think we need a package management system and a process to  
> >> maintain it.
> >>
> >> The goal is that loading and using non-core packages "just  
> >> works"
> Same goal as for Sake/Packages, and it works for me.
>
> >>  (unlike for instance SqueakMap, where loading more often fails  
> >> than succeeds because there are a lot of obsolete packages and a  
> >> dependency mechanism is missing).
> >>
> >> - There should be a responsible maintainer for each package
> >>    
> Not a realistic proposition. Better to be open to all to maintain on
> behalf of the community.

> >> - For each package there should be a known way to discuss and report  
> >> problems
> >>    
> That's just arbitrary metadata in the package definition, for more
> general topics we use the [hidden email] mailing list
> >> - A gate keeper includes and removes packages from the set depending  
> >> on their status
> >>    
> Probably too complicated to be practical.
> >> This limits the set of included packages (at least initially) but  
> >> would increase the quality and hence the user experience.
> >>
> >> Maybe there could be two sets, a stable and an unstable set. New  
> >>    
> Sake/Packages supports a stable and a beta release of each package.
> >> packages would first go to the unstable set and then move up to the  
> >> stable set after a while.
> >>
> >> An automated build process could load packages into new builds and  
> >> report the result of the tests.
> >>    
> Bob does that.
> >> The package management system does not need to be very sophisticated,  
> >>    
> Sake is as simple as possible for defining actions with dependencies.
> >> but it should manage dependencies and have a simple GUI (to search for  
> >> packages and see what is already loaded).
> >>    
> Sake/Packages uses the class browser as is, no extra GUI is required.
>
> Packages provided explore
>
> shows you what is loaded, and this should be merged into
> PackageOrganization.
>
> Keith

> El dom, 09-08-2009 a las 21:01 +0100, Keith Hodges escribió:
>  
>> Keith Hodges wrote:
>>    
>>> Adrian Lienhard wrote:
>>>  
>>>      
>>>> Hi,
>>>>
>>>> I really think we need a package management system and a process to  
>>>> maintain it.
>>>>
>>>> The goal is that loading and using non-core packages "just  
>>>> works"
>>>>        
>> Same goal as for Sake/Packages, and it works for me.
>>
>>    
>>>>  (unlike for instance SqueakMap, where loading more often fails  
>>>> than succeeds because there are a lot of obsolete packages and a  
>>>> dependency mechanism is missing).
>>>>
>>>> - There should be a responsible maintainer for each package
>>>>    
>>>>        
>> Not a realistic proposition. Better to be open to all to maintain on
>> behalf of the community.
>>    
>
> Why not, the debian project use this model since 1996 or something like
> that.
> The same package system the use report packages not maintained anymore
> (orphans and waiting for mantainer)
>
>  
>>>> - For each package there should be a known way to discuss and report  
>>>> problems
>>>>    
>>>>        
>> That's just arbitrary metadata in the package definition, for more
>> general topics we use the [hidden email] mailing list
>>    
>>>> - A gate keeper includes and removes packages from the set depending  
>>>> on their status
>>>>    
>>>>        
>> Probably too complicated to be practical.
>>    
>>>> This limits the set of included packages (at least initially) but  
>>>> would increase the quality and hence the user experience.
>>>>
>>>> Maybe there could be two sets, a stable and an unstable set. New  
>>>>    
>>>>        
>> Sake/Packages supports a stable and a beta release of each package.
>>    
>>>> packages would first go to the unstable set and then move up to the  
>>>> stable set after a while.
>>>>
>>>> An automated build process could load packages into new builds and  
>>>> report the result of the tests.
>>>>    
>>>>        
>> Bob does that.
>>    
>>>> The package management system does not need to be very sophisticated,  
>>>>    
>>>>        
>> Sake is as simple as possible for defining actions with dependencies.
>>    
>>>> but it should manage dependencies and have a simple GUI (to search for  
>>>> packages and see what is already loaded).
>>>>    
>>>>        
>> Sake/Packages uses the class browser as is, no extra GUI is required.
>>
>> Packages provided explore
>>
>> shows you what is loaded, and this should be merged into
>> PackageOrganization.
>>
>> Keith
>>    
>
> Keith, it really appear that you have built the platform to bring this
> dream a reality, but somehow (the details are not relevant now) you
> haven't materialized a "steve jobs" kind of show off of it.
> I believe your words, based on your other projects that I use. What do
> you need, as Stephan said, to bring a complete, working, and as simple
> to understand for all of us of your tools.
> This is my proposal:
>
> I think that if you can put a working example (minimal, a couple of
> packages, and the core) using Pharo, the pharo community happily will
> support you. No more fights, no more angry mails, just the working full
> simple demo.
> I offer to you access to a server with a homologated IP to install (I
> can help you here too) to setup the repositories to test your tools.
> If the community agree to use your tools and process I can also buy and
> donate the domain to host this infrastructure. In the beginning I will
> host it, if someday it grows more than I can support (bandwidth mainly,
> the space isn't problem) then we will discuss with the community to
> migrate the repos to a bigger servers or to ask for donations or some
> other party that can host it (maybe the folks of seasidehosting). We'll
> see in that moment.
>
> But, Keith, we need to see to believe and support you.
>
>
>  

>> Why not, the debian project use this model since 1996 or something  
>> like
>> that.
>> The same package system the use report packages not maintained  
>> anymore
>> (orphans and waiting for mantainer)
>>
>>
>>>>> - For each package there should be a known way to discuss and  
>>>>> report
>>>>> problems
>>>>>
>>>>>
>>> That's just arbitrary metadata in the package definition, for more
>>> general topics we use the [hidden email] mailing list
>>>
>>>>> - A gate keeper includes and removes packages from the set  
>>>>> depending
>>>>> on their status
>>>>>
>>>>>
>>> Probably too complicated to be practical.
>>>
>>>>> This limits the set of included packages (at least initially) but
>>>>> would increase the quality and hence the user experience.
>>>>>
>>>>> Maybe there could be two sets, a stable and an unstable set. New
>>>>>
>>>>>
>>> Sake/Packages supports a stable and a beta release of each package.
>>>
>>>>> packages would first go to the unstable set and then move up to  
>>>>> the
>>>>> stable set after a while.
>>>>>
>>>>> An automated build process could load packages into new builds and
>>>>> report the result of the tests.
>>>>>
>>>>>
>>> Bob does that.
>>>
>>>>> The package management system does not need to be very  
>>>>> sophisticated,
>>>>>
>>>>>
>>> Sake is as simple as possible for defining actions with  
>>> dependencies.
>>>
>>>>> but it should manage dependencies and have a simple GUI (to  
>>>>> search for
>>>>> packages and see what is already loaded).
>>>>>
>>>>>
>>> Sake/Packages uses the class browser as is, no extra GUI is  
>>> required.
>>>
>>> Packages provided explore
>>>
>>> shows you what is loaded, and this should be merged into
>>> PackageOrganization.
>>>
>>> Keith
>>>
>>
>> Keith, it really appear that you have built the platform to bring  
>> this
>> dream a reality, but somehow (the details are not relevant now) you
>> haven't materialized a "steve jobs" kind of show off of it.
>> I believe your words, based on your other projects that I use. What  
>> do
>> you need, as Stephan said, to bring a complete, working, and as  
>> simple
>> to understand for all of us of your tools.
>> This is my proposal:
>>
>> I think that if you can put a working example (minimal, a couple of
>> packages, and the core) using Pharo, the pharo community happily will
>> support you. No more fights, no more angry mails, just the working  
>> full
>> simple demo.
>> I offer to you access to a server with a homologated IP to install (I
>> can help you here too) to setup the repositories to test your tools.
>> If the community agree to use your tools and process I can also buy  
>> and
>> donate the domain to host this infrastructure. In the beginning I  
>> will
>> host it, if someday it grows more than I can support (bandwidth  
>> mainly,
>> the space isn't problem) then we will discuss with the community to
>> migrate the repos to a bigger servers or to ask for donations or some
>> other party that can host it (maybe the folks of seasidehosting).  
>> We'll
>> see in that moment.
>>
>> But, Keith, we need to see to believe and support you.
>>
>>
>>
> I've seen Keiths Seaside gui he made for Bob though I don't know if he
> wants it to be shown around. It looks nice.
>
> Here's a quick explanation for those not familiar with them.
> Sake is essentially Make for Smalltalk, allowing you to define tasks
> that can depend on other tasks.
> Bob is a build tool, which handles all the actual building using Sake
> tasks to define what to do.
>
> With Bob+Sake, you can define a build to:
> 1. Start with a defined image.
> 2. Load a set of packages into that image (either specific versions or
> the latest ones).
> 3. Apply specific fixes from the bug tracker.
> 4. Run tests.
> 5. Save the new image and export all the new package versions to a new
> folder.
>
> You can define tasks to apply features to an image such as closures or
> perform updates between versions or even update applications.
>
> For example, you can define tasks to do the following sort of things
> Pharo1.0beta -> Pharo1.0final
> Pharo1.0beta -> Pharo-latest.
> Squeak 3.10.2 image -> 3.10.2+closures.
> Squeak 3.8 image -> 3.8+closures.
> Seaside 2.8 -> 2.9.
> Pharo-latest -> Pharo-latest + Seaside-latest + your own favourite  
> packages.
>
> Once defined, these will allow anyone to repeatably and reliably  
> produce
> an updated image+packages without changing the original image. You can
> then do things like upgrade a production image based on 1.0beta to
> 1.0final just by using the same task but telling it to start with your
> production image instead of the 1.0beta distribution image. Since it
> produces a new image you don't risk clobbering your original.
>
> You should also be able to replace the update stream with distributing
> build definitions for Bob.
>
> I believe one of the key points to this setup is that you don't need  
> to
> work on the image as a single blob any more, you only work on the
> packages and use Bob to handle the messy image building stuff. That  
> does
> depend on the image being sectioned into packages of course.
>
> If I've had any misunderstandings here I hope Keith will correct me  
> but
> the system looks awesome :)
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project