[Pharo-project] [squeak-dev] Personalized systems with Treated

Chris Muller ma.chris.m at gmail.com
Thu May 5 20:02:48 CEST 2011

Well, I'm 0-2 so far from the replies understanding the point of my
story..  Oh well.

> 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.

I don't see getting more use out of something than for what it was
originally intended as a "problem".  I was just getting the work done
to quell the complaining for Magma coming from that side..

> 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.

Sure, that could be an incremental step but I wasn't in a position at
the time to go lobbying to the Pharo group for a new repository; I
just needed to get Magma done for Pharo'ites.

Question:  When is anything in "Treated" ever "consumed"?  If it's not
ever consumed, it's wasting space, so why not delete it?

> 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

Actually that describes Squeak's philosophy; they just do it in a
slower, more-incremental nature.

> 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.

Exactly; philosophical instead of practical..

>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.

Not true.  SqueakMap load scripts specify which other prerequisite
configurations are required and merges them, as needed, from SqueakMap
itself.  See Magma or Maui as an example.  Those prerequisite configs
can be browsed before loading, if desired.

I'm more interested to know the answers to these questions:

  - How does one deploy an application on Pharo that requires a
one-line change to a core system method that is not acceptable to the
Pharo gods?

  - How does one deploy an application on Pharo that loads code from
external web-sites?

  - How does one deploy an application on Pharo that requires external
graphics, videos, XML or other resources?

  - How does one deploy an application on Pharo that requires an
object-graph to be loaded internally into the image that was pre-built
using another tool (e.g., NOT generated via code)?

These questions are much more important to me than "it isn't a package
management system".  If Metacello could do all of these things, I
might be interested..


More information about the Pharo-project mailing list