[Pharo-project] [squeak-dev] Personalized systems with Treated
miguel.coba at gmail.com
Thu May 5 17:52:06 CEST 2011
This workaround is valid although not less a workaround.
The problem with those other repositories is that they are for specific
uses, as Stef said in other post, the Treated repository is for packages
integrated in current Pharo. So, of course you could post some package
there but it wont belongs to there really.
This workaround it could be better implemented if the package with
specific changes will be pushed to some dedicated compatibility
repository where everyone can push every package and use it in their
install procedures. That would be better.
Now, lets remember that for Pharo at lease, backwards compatibility is a
"great to have" feature not a "must have at all means" feature. So if
sometime, with some release, current or future, a break with the past is
to be made, it will be made. That is for sure. There can be a few people
that will be affected by this (in this case that they can't install
something just like they could yesterday, but hey, this is life, as
Markus said, no progress is to be dead already) but the majority won't
care/will be happier because it is always better for a few persons to
fix some problems than the entire project to stall waiting to be all for
everyone and always.
The changes of core libraries, (collections, kernel, etc) almost sure be
ported to pharo from squeak and if some package release can't work
because of a missing library in Squeak not yet in Pharo that won't be a
big problem. Next release will work, when Pharo has the fixes. We don't
worry, one step a time. And nobody has died by waiting a little for some
So in the end, I think that this is a non-issue, just a minor effect of
the vision of Pharo that is solved with a little of time and patience.
Other thing, we really don't like changesets or gofer scripts for
installing anything on Pharo (even if we really like gofer). Why?
Because they aren't a package management system. The end result could be
the same: the packages are installed in the system, that is granted, but
the capability of Metacello of declaring which other configurations it
depends on and the one of querying the configuration to see the full
list of packages to be installed is something that no gofer script,
installer script or SqueakMap feature can handle right now without
downloading everything to check.
El mié, 04-05-2011 a las 21:35 -0500, Chris Muller escribió:
> To support Magma 1.2, I introduced some changes to OrderedCollection
> into the Squeak trunk some time ago. To deliver Magma to Pharo users,
> I needed to have these same enhancements in Pharo 1.1 and 1.2. But
> they were already released, so how was this solved?
> My first instinct was to deliver a change-set; the classical way to
> modify the system. But I know dirty packages are unattractive, and
> besides that the only way to achieve one-click load of something
> involving a change-set + MC-packages in Pharo is with a SAR - overkill
> since Magma is just MC packages; no resources. I really wanted to
> release Magma 1.2 to Pharo with just a Gofer script.
> So, I decided to import the same changes I made to Squeak's
> OrderedCollection into Pharo's and then save that new version to the
> Inbox and adjusted my Gofer script for loading Magma to merge that
> version of Collections from repositories: Pharo, Inbox, TreatedInbox.
> I knew they would accept it, thank you Pharo, BUT it's nice to know
> that I could actually deliver my application without having to wait
> for it to be integrated, or worry even if it didn't get accepted; that
> chain of repositories should work immediately and forever, no matter
> the outcome of acceptance.
> Thanks to MC merging, this is as unintrusive as it can be; in case
> someone runs with their own "personalizations" to the Collections
> package, loading Magma won't clobber them; nor will updating with
> official Pharo-released patches, because those are merged too.
> With the context of this experience, I came to view the "Treated"
> repository with a new respect; enabling a non-core developer to
> personalize system packages for my application..
> - Chris
More information about the Pharo-project