I think package management and source control are perpendicular. What bugs me most about MC is mostly that it seems to conflate the two pieces of functionality in a way that doesn't accomplish anything that I can see (enlighten me! What am I missing here?)

I'd rather not have to check in three times to change behavior in three different packages that are a part of a core system or application. I'd prefer to make a single commit with all of the changes across all of the packs I've touched as an atomic thing, so that you can see the full context of what I've changed in the diff. Making separate commits forces the integrater to go digging for correlations between commits in order to understand the changed, which totally sucks when there's money going down the tubes by the minute because production is down and I'm staring down a merge conflict while trying to ship a hotfix. 

I don't really see what the package metaphor buys me when I'm developing, though I do (obviously) see the value in being able to load and unload hunks of functionality.

What I'm saying in essence is that by conflating the ideas in one tool, the tool has to be more complex than if we kept these things as separate concerns. 

Another way to say that is, without real modularity, the only value I see in package management is operational: loading and unloading things. This has nothing to do with revision control in my mind. 

Andreas' point is well taken, BTW: it's what we've got, and changing it is a lot of work. I'll even add to that: currently MC/SS is the only bridge between Squeak and Pharo, and if we change this stuff in Squeak without also changing it in Pharo, we drive yet another wedge between the two systems/communities, and make (for those of us who dream of it) a future merging of forks much more difficult. 

All the same, dog gone it, I'm going to bag on what I see broken in the MC design until I'm blue in the face. I talked to someone once who said MC2 goes some distance in terms of separating the two concerns, but I've not used it, and at this point just merging that in will be painful.

On Apr 8, 2011, at 8:16 AM, Chris Muller <asqueaker at gmail.com> wrote:

> I'm having trouble understanding what everyone is criticizing here.
> Is it that PackageInfo does not keep its own state?  That it relies on
> the category names of classes and methods to know what is "contained"
> in it?
> 
> Or is it a criticism of the notion of having a delineation of
> classes+methods at all that make up a single executable "program"?
> 
> You all are smarter than I, I'm just trying to learn..
> 
>> PackageInfo is an awful fake. It not much better than a dummy state holder,
>> while various parts of system (including MC) trying to play with it.
>> 
>> It would be much nicer at some day to have a proper reification of
>> packages in system, so they
>> could be in charge what goes inside them, and what are relationships
>> between them.
>> 
>> I dreaming that some day we could do stuff like:
>> 
>> newClass := Object subclass: #Foo.
>> 
>> myPackage add: newClass.
>> myPackage add: (Object>>#extensionMethod)
> 
> Wouldn't that be a separate step though?  Right now, we kill two birds
> with one stone:  categorizing classes and methods, AND assigning their
> Package at the same time.  Wouldn't separating these two activities
> lead to extra work and ambiguity about what code is in what
> package(s)?
> 
>> and even:
>> 
>> myPackage add: icon.
>> 
>> and then:
>> 
>> myPackage serializeTo: aStream.
>> 
>> and then:
>> 
>> myPackage := Package loadFrom: aStream.
>> 
>> what could be more simpler and powerful?
> 
> As for the icon, with MaSarPackage, you can simply override
> #resourceNames in your own PackageInfo subclass and it handles the
> serialization of those files into the Smalltalk-Archive (SAR)
> automatically.  Since that method is saved with the MC package, it
> only needs to be done once.  Very simple.
> 
>>> There's no actual modularity going on with them, which is confusing to new people who've had modules in every other language that were namespaces.
> 
> I just don't understand this statement.  The modularity is that of a
> set of code-elements that work together to solve a real-world
> problem..
> 
> - Chris
>