[Pharo-project] [squeak-dev] Community Supported Packages
Mariano Martinez Peck
marianopeck at gmail.com
Mon May 17 08:54:13 EDT 2010
On Mon, May 17, 2010 at 2:14 PM, Torsten Bergmann <astares at gmx.de> wrote:
> I tried to follow the discussion on both lists regarding supported packages
> and how/where to manage them by using Metacello. I can not give complete
> since I go with Göran here who said "I need to read your thoughts once more
> before giving proper feedback." and I think we all should take the time to
> think about all the implications the different approaches have.
> With this discussion we set up the base for the future of package
> but also for collaboration amongst the communities, how images are built,
> I'm sure we all want to blur the line between in and out of the (whatever)
> and share/reuse as many code/packages as possible within the broader
> (Squeak, Pharo, Cuis, Gemstone, ...). So:
> Goal Nr. 1 is: if it is not in my environment then just load it.
> Goal Nr. 2 is: if it is loaded it should work in my environment since it
> in anything it needs to work
> Currently the discussion and actions seem to focus on where to put the
> configurations (into the image vs. in repositories per version). I'm in
> of the latter since that is easier to handle and share between platforms
> while having them in the image would limit people who work on various
> platforms, it would not scale and eat more resources for maintenance.
> My fear is also that if you have the configurations within the image then
> we all will end up with something similar to the unmaintained SqueakMap
> registrations. With external repos we can also feed CI-Tools (Hudson build
> server, ...)
I agree with all this.
> The only benefit from the "maintining configs in-image" would be that
> it would be easy to build a UI similar to SqueakMap/Universe Browser.
> This is something that has to be solved - especially for Pharo since
> it is not very "user friendly" today, but AFAIK work already started with
> "Loader" project. Agree with Andreas that Metacello needs more work and
> a good browser of available configs would be a plus.
I don't agree here. You DON'T necessary need to have the packages inside the
image to have a UI. If you are using this tool, is because you have internet
connection, otherwise you won't be able to install anything. So, if you have
internet connection, no need to have configurations in the image. They will
be difficult to update and to manage. Even more, having an external repo
pero version, give us a "UI" as you want but reusing the tools we already
have. Ok, it is not perfect, but it works:
As I say, when you distribute Pharo1.0 you include the
Pharo10MetacelloRepository already added. Then, you open Monticello Browser,
browse the repo Pharo10MetacelloRepository, choose the one you want, you
load it with Monticello, and then just evaluate: ConfigurationOfXXX load.
You can even put a class side initialize for that if you want.
> But thats not the main question. Even if Squeak decides to have the
> "in-image" and Pharo decides for external configs one can mix them:
> An in-image ConfigurationOfMyApp just loads the
> where the last one is maintained in an external repo and the internal
> config is for convenience to just load it.
> However - I have to reread all the arguments and think about all this.
> But with a better acceptance of Metacello there will be more to come and
> to discuss!
> Lets think about the implications for anything above the virtual machine:
> Squeak is currently maintained as a "full image" using the trunk process
> while Pharo already switched to a "small core + external packages" model.
> The "pharo core" image (which is not Pharo!) is getting stable and
> smaller and one can already create a Pharo image right from the
> "ConfigurationOfPharo". That is there and working.
> I'm not saying that Squeak is not getting stable (I'm still a Squeak AND
> Pharo guy)
> but it is a different approach to build the end result that we later
> announce on
> our websites.
> If Squeak jumps on the Metacello config bandwagon it may also have to think
> jumping onto the "small core + external packages" model. At least to me
> this would be the next logical step.
> This leads to several questions:
> - could this small core could be the same for all of us - especially since
> we currently fix stuff in Cuis, Squeak and Pharo mostly the same way
> - could this small core be reduced to a minimum set of objects and a
> that is able just suck in the things defined in package configurations
> of packages that work together
> - would any specific assembled/deployed image not just be a special distro
> of the "small kernel" + selected packages (similar to the linux world)
> So "Squeak" may later be the distro with media/fun/experimental packages
> or etoys and "Pharo" may later be the distro with packages oriented
> towards commercial development.
> However then the lines are blurred then and if you have the common core on
> your disk you can even create your own distro with Seaside and Etoys ...
> Pharo will follow the path "kernel" + selected packages" and external
> config path anyway since this is already discusssed and prepared.
> >From what I understand so far a repo for Pharo 1.1. will appear soon
> with freezed/working configs and a build structure will be set up.
> So lets see how this works out and if successfull if Squeak will
> adapt it too.
> Just my 2 cents. Expect additionally cents after getting more time to
> think about all this ...
> GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-dev