Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
Proposed Smalltalk project directory structure

##Monticello Package Structure

The basic idea is to store individual methods in files so that git can manage method-level history. The split between classes and methods in the definitions directory is differentiate between classes defined in a package and external methods defined in the package:

+-Sample-Core.pkg\
  +-snapshot\
  | +-classes\
  | | +-SampleCore.class\
  | |   +-SampleCore.st
  | |   +-instance\
  | |     +-author.st
  | +-extensions\
  |   +-Object.class\
  |     +-instance\
  |       +-isSample.st
  +-.filetree
  +-categories.st
  +-initializers.st
  +-package
  +-version

##Project Structure

The classic Monticello style is to store all packages in a single directory. The actual name of the directory doesn't matter. The specs in the metacello.st file contains the classic Metacello spec information:

+-sample
  +-core/
  | +-metacello.st
  | +-Sample-Core.pkg\
  | +-Sample-Platform.gemstone.pkg\
  | +-Sample-Platform.pharo.pkg\
  | +-Sample-Platform.squeak.pkg\
  | +-Sample-Tests.pkg\
  +-doc/
  +-license.txt
  +-README.md

##Alternate Project Structure

Packages are distributed across the core, platform, and tests directories. The package structure is the same, but the Metacello spec information is different so that packages can be referenced in the different directories:

+-alternate
  +-core/
  | +-metacello.st
  | +-Sample-Core.pkg\
  +-doc/
  +-platform/
  | +-metacello.st
  | +-Sample-Platform.gemstone.pkg\
  | +-Sample-Platform.pharo.pkg\
  | +-Sample-Platform.squeak.pkg\
  +-license.txt
  +-README.md
  +-tests/
  | +-metacello.st
  | +-Sample-Tests.pkg\
@vonbecmann

This comment has been minimized.

Copy link

@vonbecmann vonbecmann commented Feb 25, 2012

the directory definitions/methods contains extensions.
When you work with monticello those methods are called extensions and they appear in the category *Extensions. am i right?
so why don't you use the name extensions for that directory? ie, definitions/extensions.

@dalehenrich

This comment has been minimized.

Copy link
Owner Author

@dalehenrich dalehenrich commented Feb 26, 2012

Excellent idea! makes a ton of sense!

@timfel

This comment has been minimized.

Copy link

@timfel timfel commented Feb 26, 2012

I'd prefer the "classic" structure, if only because I won't have to look through so many trees. Also, I think it'd make it easier for me to change Gitocello to support it ;)

@dalehenrich

This comment has been minimized.

Copy link
Owner Author

@dalehenrich dalehenrich commented Feb 26, 2012

Tim,

I was considering that both could work ... it would be up to the project maintainers whether or not to break the project up into "sub-projects" or not. Seaside has ~100 packages ... that's too many to keep in a flat directory structure ... don't you think?

@dalehenrich

This comment has been minimized.

Copy link
Owner Author

@dalehenrich dalehenrich commented Feb 26, 2012

Tim,

The GNU Smalltalk port also breaks Seaside up into multiple directories ... https://github.com/bonzini/smalltalk/tree/master/packages/seaside, even though a lot of the individualt Monticallo packages appear to be collapsed into a single .st file...

I am casting about for ideas to make it easy for one to use subdirectories without requiring subdirectories... keeping in mind that I have to make it easy for me to change Metacello to support it, too:)

@dalehenrich

This comment has been minimized.

Copy link
Owner Author

@dalehenrich dalehenrich commented Feb 27, 2012

Bernardo,

Following the line of thought that 'extensions' is a better name than 'methods', perhaps 'snapshot' will be a better than 'definitions'....

@vonbecmann

This comment has been minimized.

Copy link

@vonbecmann vonbecmann commented Feb 27, 2012

yes, i agree. The snapshot of a mc package with classes and extensions. it sounds good to me

@dalehenrich

This comment has been minimized.

Copy link
Owner Author

@dalehenrich dalehenrich commented Feb 27, 2012

Then a 'traits' directory probably makes sense for keeping trait definitions as well..

@sebastianconcept

This comment has been minimized.

Copy link

@sebastianconcept sebastianconcept commented Mar 3, 2012

Well... the universe of devices is increasing and the market is getting "addicted" to that so it's reasonable to assume that every software product should work on different platforms.

In the other hand... can't you have completely different projects, one per platform, to achieve the same result?

But if this way is easier for smalltalkers then it would make sense.

@dalehenrich

This comment has been minimized.

Copy link
Owner Author

@dalehenrich dalehenrich commented Mar 3, 2012

With git, I think that using separate branches for the different platforms makes a lot of sense ... but when you do that it makes sharing fixes between the various branches a bit difficult ... with the standard git merge you to resolve conflicts and accept all changes, but having a branch per platform means that you want to preserve the platform specific differences and only accept the "common" changes ... which requires some discipline and knowledge ...

In the end I think that we need to have some experience with different techniques and pick the one that has the fewest flaws

@vonbecmann

This comment has been minimized.

Copy link

@vonbecmann vonbecmann commented Mar 7, 2012

i forked it (here git://gist.github.com/1997065.git) and changed the name of the directories

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment