Monticello and PackageInfo

>> If I'm asking why a class should belong in two PackageInfos it's only
>> fair I answer why it shouldn't:  Because by the PackageInfo domain
>> model mirroring MC's model, they are able to work together better.
>> For example, the use-case I cited previously was one-click building
>> .sar packages (MaSarPackage on SqueakMap).  Utilities like that are
>> much easier to build and maintain when the cardinalities between the
>> models match.
>
> A class can belong to more than one Monticello package too.

By "belong to" I assume you mean "defined in".  Even still, "could"
does mean "should".  Again, I ask for practical usage-scenarios where
this is helpful -- in fact, you might start with why is it /not
detrimental/?

The prior example about being detrimental was ignored -- If you have
package "Foo" and package "Foo-Bar" and make a change to a method in
Foo-Bar, you now have two dirty packages.  Which one are you gonna
save?  Which one are you gonna load?  They're stepping on each other
so what normal use-case is this?

My goal w.r.t. this issue is to have a simple, practical model useful
for connecting Monticello elements with their in-image counterparts.
What's yours?

> ... Even still, "could"
> does mean "should".

s/does/does not

On Wed, Apr 03, 2013 at 05:55:14PM -0500, Chris Muller wrote:
My practical use case is that I have a package called OSProcess that I have
been maintaining for many years. The package can logically be split into a
number of sub-packages (OSProcess-Base, OSProcess-Unix, etc). At some point
in the past I managed to convince myself that it would be a good idea to
split OSProcess into sub-packages because I thought that this would be
"more modular". So I did that, and now I have lots of very modular looking
packages. But I also kept the original OSProcess package, because it turned
out that in real life nobody cared about the sub-packages, and it ended up
being a big pain to keep track of all the versions of sub-packages when most
people just wanted to load OSProcess, and for me maintaining the package the
only thing I cared about was "what version of OSProcess do you have installed
that is causing a problem."

In a perfect world, people would not make strategic blunders like this. But
I am not perfect, so now I have classes that are part of both the OSProcess
package and the OSProcess-Base package. I regret the mistake, but I am happy
that the tools do not prevent me from managing my way through its consequences.
For people who use OSProcess, nobody even seems to have noticed the mess. They
just load it from SqueakMap or ConfigurationOfOSProcess and something that
works gets installed.

So for me it is important that a class can belong to more than one package.

Dave

In Dave's case, I'm wondering whether simply renaming OSProcess-Base
et al back to OSProcess would be appropriate.

In Colin's case, it wasn't clear to me how the 1:many cardinality
helps -- e.g., whether the packages are OmniBrowser-Core +
OmniBrowser-TestFixtures (2 distinct packages) or just OmniBrowser +
OmniBrowser-TestFixtures (a hierarchy of 2 packages); under either
case the fact of the broken OB code leaves a dirty
OmniBrowser-TestFixtures package is still the same solution --
reloading OmniBrowser-TestFixtures.  The only difference I see is that
OmniBrowser package would report dirty too, even if it wasn't, just by
having run the tests.

So I remain skeptical but it seems I'm outvoted.  Thank you for
discussing it nonetheless -- some of our best decisions as a community
were because of good discussions.


On Thu, Apr 4, 2013 at 11:44 AM, Colin Putney <[hidden email]> wrote: