On 05.08.2010, at 17:09, Miguel Enrique Cob� Mart�nez wrote:
El mi�, 04-08-2010 a las 23:32 -0300, Javier Pim�s escribi�:
Maybe I saying nonsense, if that is the case just ignore me but... why
have many packages that do almost exactly the same? Aren't you going
to get a lot of repeated code lying around in different packages? ie.
I think most packages have almost exactly the same baselines for
pharo1.x. Maybe it's possible to call the methods baselineXXForPharoXX
and let them stay in the same class and package? Or maybe adding other
pragma to specify which pharo version each baseline/version describes.
I'm sure there could be other solutions. That way you'd have all the
configurations in the same place and also reuse code if needed instead
of duplicating it.
I think Javier is right. I, too, have problems to understand how this should work. A lot of the ConfigurationOfxxx files are about software projects that run on pharo and aren't _part_ of it. Just take a project like seaside. That is a project that runs on a lot of platforms (hence the existence of grease).
Clarity. As is very likely that different releases of a package will
have distinct requirements in:
- dependencies
that is what metacello is all about
- preinstall/postinstall actions
- registering with system services (menu, mail systems, sockets,
startup/stop list)
that is platform specific. For seaside that needs to be solved from the seaside crew otherwise they won't stay cross-platform very long. And I think there is no point in many people writing in a ConfigurationOfSeaside30 file. Those files should be very dependent on the people writing seaside. Do you think you will add pharo1.1 stuff to the file?
- number of monticello packages composing the package you're installing
that's dependencies
- use of system infraestructure (announcements, transcript, menus, help
system)
again platform handling
it will be a nightmare to have code to cope with all those conditions in
a single monolithic giant metacello package, even if metacello is
capable of do it.
What if after 4 years of development the package has had 15 releases,
that will means that you'll have possibly 15
baselines/predoits/postdoits all listing in the method pane of the
browser. To someone trying to understand the configuration, it will be a
lot of junk to discard before he understand only the bits that matter
for the release he is interested in.
So, it is healthy to have a distinct configuration in each release (even
if in the current release started as a copy of the previous release
configuration), to crop the things the _maintainer_ thinks are not
needed anymore or simply that he doesn't want to maintain anymore. All
the software has a lifetime and distinct repositories gives us the
possibility to determine the time to end support for a given release
Please correct me if I'm wrong. By copying the configuration files you make a snapshot of the project without the possibility to alter anything. The configuration file itself is modified by the software project the file is for. Probably the software project does not want anyone to write in the config file.
To me a central repository is essential. It is a single well-known source and it carries the idea of cross-platformness :) Isn't that would you are trying to solve not just another ConfigurationOfXXX file. For the moment let's call it ConfigurationOfPharo10Universe. There you can refer to every single version in another ConfigurationOfXXX file that is said to be runnable in that platform. And you can decorate it with pre-/postDoits as you want.
I think that most of this software management tasks are solvable by a description of "requires" and "provides". And metacello solves it well. As an example let's think of an example like ConfigurationOfPharoWebDeveloperImage (maintained by the image provider). The developer image develops linearly hence no version number in the file. The ConfigurationOfPharoWebDeveloperImage has dependencies to 20 other software projects that are all defined in a ConfigurationOfPharo11Universe (maintained by the community). Let's say it has a dependency on 'Seaside 3.0'. ConfigurationOfPharo11Universe offers 'Seaside 3.0' and has a dependency of 'Seaside 3.0.3' in ConfigurationOfSeaside30 (maintained by the seaside maintainers). ConfigurationOfSeaside30 has a dependency to 'Grease 1.0.3' in ConfigurationOfGrease. So let's asssume finally that ConfigurationOfGrease would have a dependency to 'Pharo 1.1' when run under pharo1.1 or to 'Pharo 1.1 compat package' when run under pharo 1.0 (metacello allows us to do that). All of these descriptions require and provide anything. And the descriptions are services offered from one group to another taking a certain responsibility. You can always rely on things like "Seaside 3.0" if you trust the people and if not than you use "Seaside 3.0.4rc2a".
What I wanted to say is that there are plenty of situations where you want to cluster software packages together. By copying the files you just double to stuff without being able to tweak. Removing the packages from the MetacelloRepository as Stephane suggested would just make them platform dependent. Having less files and clear roles who might change them is something achievable IMHO. Tearing things apart (by copying) lowers sometimes integration effort. Or to say with view from the XML world: "If you want to integrate/cooperate than XML schema is for you If you don't want to do that than use XML namespaces".
Norbert
On Wed, Aug 4, 2010 at 3:18 PM, Dale Henrichs <dhenrich@vmware.com>
wrote:
Miguel,
I think that this kind of approach makes lots of sense ...
I've toyed with the idea of a "white list" of configuration
versions, but someone would have to be responsible for
maintaining the "white list" and the users would have to
responsible for using the "white list" ...
A repository per version is very simple and gives the
maintainer flexibility in managing releases.
Dale
Miguel Enrique Cob� Mart�nez wrote:
El mi�, 04-08-2010 a las 19:52 +0400, Andrey Larionov
escribi�:
Why there should be repository per release? As
i know
MetacelloConfiguration already contains
information about compatible
Pharo versions.
Because is cleaner and as the releases of Pharo
diverge a lot more, the
code to install package becomes full of conditionals
to handle the
distinct issues with each pharo release.
For example, Magma. Magma 1.1r1 worked good in any
pharo 1.0, 1.1 and
1.2.
But Magma 1.1r2 doesn't work anymore on Pharo1.0
because Pharo 1.0
doesn't have the classes DirectoryEntryDirectory and
DirectoryEntryFile
that are used by the new magma version.
So I had to modify the configuration with conditionals
an several
variations of preDoits and postDoits and test what
version image is
ConfigurationOfMagma is being ran. After a couple of
hours I gave up.
The correct solution is to have a specific
ConfigurationOfMagma for each
released pharo version.
This have benefits also:
- It permits the unstable repository to heavily update
the
ConfigurationOfXXX without disturbing or broke the
stable ones.
- It permits the ConfigurationOfXXX code to remain
clean, without a
conditionals for every posible combination of release
image version and
package to be installed version
- It permits the maintainer of a ConfigurationOfXXX to
decide when to
stop supporting old version of a certain package by
deleting the old
versionXX: methods of the ConfigurationOfXXX in the
newer pharo
releases. Not always is good to be able to install
each and every
version of a package in the newest release of pharo
(maybe even old
versions won't work in the new releases, like the menu
registration
issue or classes that doesn't belong to the core
image)
- It permits to issue maintenance ConfigurationOfXXX
releases for a
stable or "old-stable" image releases, without
altering the
configurationOfXXX in other repositories
Cheers
2010/8/4 Miguel Enrique Cob� Mart�nez
<miguel.coba@gmail.com>:
El mi�, 04-08-2010 a las 11:46 +0200,
Torsten Bergmann escribi�:
Hi Miguel,
hey, nice! If we follow this
convention then it is easy to
implement
a universe browser that
selects the correct universe
repo and
displays all loadable
versions. Loading stuff should
just be
a few clicks away - I
personally hate all this
MC/Gofer typing ...
Attached is a quick/simple
implementation of such a
browser:
Mann, Sie sind �ber schnell!
I tested it in PharoCore 1.0 and
worked after a few changes, but the
interface is cool. +1 to aim it be the
default universe browser in 1.2.
Simple, to the point.
In Pharo 1.0 I had:
- Open it with Universe open (doesn't
register on menu because of the
lacking pragmas)
- UniverseBrowser pharoUniverse
returns PharoCore1.0 instead of
Pharo10
to build the universe name. This could
be changed in two ways:
- Add a system property that states
the image repository:
SystemVersion current universeName
"Returns Pharo10 for image
releases 1.0, 1.0.1, 1.0.5, etc)
- Use the equivalent method in the
gofer package I uploaded to
PharoInbox (if it is approved, so
there is only a unique source for
converting image version string to
universe names)
Other than that, I like the browser.
- file in the attached
changeset (I tried in Pharo
1.2)
- open via World menu ->
"Universe Browser"
- select the configuration
you want and from the context
menu choose
-- "Load configuration"
-> only the config is loaded
-- "Load configuration and
latest version" -> the config
and lates version is loaded
Have fun! I used Pharo 1.2 -
should work in Pharo 1.0 and
1.1 too
(havent tested).
Bye
T.
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Cheers
--
Miguel Cob�
http://miguel.leugim.com.mx
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
Javier Pim�s
Ciudad de Buenos Aires
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
Miguel Cob�
http://miguel.leugim.com.mx_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project