GitHub Sample project WTF?

I've created a Sample project on GitHub[1] and I'd like to invite some WTFs.

I haven't decorated the Sample project with any documentation (yet) and your WTFs will help guide me:)

I would really like for you to take a couple of minutes and look at the ConfigurationOf and BaselineOf for the Sample project. This is your first chance to look at where I'm planning to take Metacello, so now is a good time to take a look at what I've been up to and let me know what you think.

The Sample project is small enough (Sample-Core and Sample-Tests) to be comprehensible...

When you've got a spare 15 minutes or so get a fresh Pharo1.3, 1.4 or Squeak4.3 image and bootstrap the MetacelloPreview project so you can take a look (Squeak guys skip the leading Deprecation statement):

Deprecation raiseWarning: false.
"Get the Metacello configuration"
Gofer new
  gemsource: 'metacello';
  package: 'ConfigurationOfMetacello';
  load.

"Bootstrap Metacello 1.0-beta.32, using mcz files"
((Smalltalk at: #ConfigurationOfMetacello) project
  version: '1.0-beta.32') load.

"Load the Preview version of Metacello from GitHub"
(Smalltalk at: #Metacello) new
  configuration: 'MetacelloPreview';
  version: #stable;
  repository: 'github://dalehenrich/metacello-work:configuration';
  load.

(Smalltalk at: #Metacello) new
  configuration: 'Sample';
  version: #stable;
  repository: 'github://dalehenrich/sample:configuration';
  load.

Beyond the standard Metacello load, you'll see several new classes:

  ConfigurationOfMetacelloPreview
  BaselineOfMetacello
  BaselineOfFileTree
  ConfigurationOfSample
  BaselineOfSample

While I am interested in your WTF about the first three, if you've got only limited time, take a look at the last two:

  ConfigurationOfSample
  BaselineOfSample

The Sample project should give you a clear picture of the specifications for a GitHub project. I'll touch on some of the highlights.

The Sample project was downloaded from GitHub without using the standard Monticello HTTP repository. Instead a zipfile of the repository contents is downloaded and unzipped into the git-cache directory (in parallel with package-cache). In the MonticelloBrowser you will see a number of github: repositories. WTF?

The ConfigurationOfSample has versions 0.8 and 0.9, but when you look at the spec methods, you just see a #baseline: reference and no mcz files. WTF?

The BaselineOfSample has a single baseline: method and it should look like a familiar baseline version spec, just in a separate class. WTF?

Git isn't involved for downloading and installing projects from GitHub. Curl and unzip are being used and are called using OSProcess. WTF?

Version 0.8 references a specific git commit and will not change ... so it's a lot like a traditional released version for a Metacello configuration...only the unchanging part is enforced by git.

Version 0.9 references the HEAD of the master branch...If you load version 0.9 (which is blessed as #development BTW) you will get the #bleedingEdge version of the project ...

ConfigurationOfSample is managed in the configuration branch of the Sample project[2]. The only package on the configuration branch is the ConfigurationOfSample. WTF?

BaselineOfSample is managed along with the rest of the packages in the master branch of the Sample project. It is embedded with packages and changes whenever new packages or projects or groups are added or removed ... otherwise it is left untouched.

Nowhere do you see fully qualified mcz file names...except in the MonticelloBrowser ... so mcz versions are being maintained, it's just that for a git/github project you don't have to constantly change them, like you do in a traditional Metacello project.

At the moment, the MetacelloPreview is functional, but only the `load` command has been fleshed out. Not looking for scripting API WTF, but if you've got some ... fire away:)

Scratch your head, wrap your brain around the concept of BaselineOf, ask questions, yell, now is a good time:)

The Sample project is the future of Metacello...

Dale

[1] https://github.com/dalehenrich/sample
[2] https://github.com/dalehenrich/sample/tree/configuration

Overall, this is very exciting. Thank you Dale for all this hard work!!!

github's collaboration features alone have had Dale and I giddy, while we commented line-by-line via the web ui on changes I made. Issues can easily be linked to commits. And once a pull request is made to the main project, the pull request itself becomes the issue tracker. You can request a pull early, discuss the changes, and keep committing to that branch as the discussion progresses. See https://github.com/dalehenrich/metacello-work/pull/78 for an example of a conversation we had in a pull request, referencing (and linked to) specific lines from a commit, that led to additional commits. It's like Pharo's Slice concept... on steroids ;-)

Dale Henrichs wrote

The ConfigurationOfSample has versions 0.8 and 0.9, but when you look at the spec methods, you just see a #baseline: reference and no mcz files. WTF?

So I guess for each project, there'll be a branch-per-platform (e.g. pharo1dot4 branch, squeak4dot3 branch, etc.). I can't envision this clearly enough, but my gut says this could make maintaining cross-platform projects much easier...

Dale Henrichs wrote

The BaselineOfSample has a single baseline: method and it should look like a familiar baseline version spec, just in a separate class. WTF?

Very cool! Much simpler...

Dale Henrichs wrote

Git isn't involved for downloading and installing projects from GitHub. Curl and unzip are being used and are called using OSProcess. WTF?

Whatever we have to do to make it work, right? We can always replace parts later if/when we feel the pain.

Dale Henrichs wrote

ConfigurationOfSample is managed in the configuration branch of the Sample project[2]. The only package on the configuration branch is the ConfigurationOfSample. WTF?

This is strange to me... Why a separate branch? I was confused after skimming this thread, when I went to the project on github and couldn't find the Config class... Also, we should think about the new users this will attract - is it standard git/github practice to use a branch like that i.e. to maintain code that's part of the main project but will never be merged into master? I could see keeping the branch for development, but I feel like commits should be merged into master. Take this with a grain of salt... just a gut reaction.

I'm eagerly awaiting 1.0.32...

Cheers,
Sean

On Saturday, July 14, 2012 3:35:11 PM UTC+1, Sean DeNigris wrote:

Overall, this is /very/ exciting. Thank you Dale for all this hard work!!!

Dale Henrichs wrote
>
> Git isn't involved for downloading and installing projects from GitHub.
> Curl and unzip are being used and are called using OSProcess. WTF?
>
Whatever we have to do to make it work, right? We can always replace parts
later if/when we feel the pain.

Dale Henrichs wrote
>
> ConfigurationOfSample is managed in the configuration branch of the Sample
> project[2]. The only package on the configuration branch is the
> ConfigurationOfSample. WTF?
>
This is strange to me... Why a separate branch? I was confused after
skimming this thread, when I went to the project on github and couldn't find
the Config class... Also, we should think about the new users this will
attract - is it standard git/github practice to use a branch like that i.e.
to maintain code that's part of the main project but will never be merged
into master? I could see keeping the branch for development, but I feel like
commits should be merged into master. Take this with a grain of salt... just
a gut reaction.

I've been meaning to respond to Sean's comments now is a good time:)

will come back around to any of Sean's comments that are address here.

Embedded comments ...

----- Original Message -----
| From: "Patrik Sundberg" <[hidden email]>
| To: [hidden email]
| Sent: Monday, July 23, 2012 10:32:39 AM
| Subject: [Metacello] Re: GitHub Sample project WTF?
|
|
|
| On Saturday, July 14, 2012 3:35:11 PM UTC+1, Sean DeNigris wrote:
|
| Overall, this is /very/ exciting. Thank you Dale for all this hard
| work!!!
|
|
|
|
| indeed - git and github on the horizon certainly helped push me into
| trying some hands on smalltalk development.

Cool!

|
|
| Dale Henrichs wrote
| >
| > Git isn't involved for downloading and installing projects from
| > GitHub.
| > Curl and unzip are being used and are called using OSProcess. WTF?
| >
| Whatever we have to do to make it work, right? We can always replace
| parts
| later if/when we feel the pain.
|
|
|
| seems ok as a start, one can decide later if there's mileage to
| working with local git repo clones or not.

Right ... IIRC one of the possibilities with embedded git support (Max Leske and Camillo Bruni) is that we can directly attach to the GitHub repository and use the web api ... so as the embedded git support matures we can definitely expand capabilities...

|
|
| Dale Henrichs wrote
| >
| > ConfigurationOfSample is managed in the configuration branch of the
| > Sample
| > project[2]. The only package on the configuration branch is the
| > ConfigurationOfSample. WTF?
| >
| This is strange to me... Why a separate branch? I was confused after
| skimming this thread, when I went to the project on github and
| couldn't find
| the Config class... Also, we should think about the new users this
| will
| attract - is it standard git/github practice to use a branch like
| that i.e.
| to maintain code that's part of the main project but will never be
| merged
| into master? I could see keeping the branch for development, but I
| feel like
| commits should be merged into master. Take this with a grain of
| salt... just
| a gut reaction.

I've taken this approach, because when you do multi-platform support, I think a branch per dialect is the way to go ... (open for WTF as well) and if you do use multiple branches, which version of the config on which branch is the correct version to use ... I settled on having a configuration branch so that there'd be only one place to EVER look for the correct version of the configuration ...

I've considered separate repositories, etc. and don't like any of the alternatives ... Keep in mind that the ConfigurationOf in a git/github world is becoming a tag repository ... the BaselineOf (which _is_ kept in each branch) can be used to load the project, so the configuration isn't necessarily the primary entry point for developers ... users of a project will still use ConfigurationOf to reference the project from their BaselineOf so knowing that no matter what else is going on you can find the ConfigurationOf on the configuration branch in the project seems to make sense to me.

Sooo, we really need to work this out in practice ...

|
|
|
|
| this was strange to me as well. I wouldn't mind the ConfigOfXXX
| package being part of the "normal" master branch (or other branches
| like stable, feature branches, etc) on a first impression. the
| reasons to split it out that I can think of are:
| - not affect commit versions of the project code by changes to the
| ConfigOfXXX
| - make it easier to distribute the ConfigOfXXX package on its own

Right on...

You are going to embed a SHA in the ConfigurationOf. You have to do the commit before you know what the SHA of the commit is, so the ConfigurationOf that is part of the commit will ALWAYS be wrong....it is just simpler to keep the ConfigurationOf on it's own branch...

Dale

----- Original Message -----
| From: "Sean P. DeNigris" <[hidden email]>
| To: [hidden email]
| Sent: Saturday, July 14, 2012 7:35:11 AM
| Subject: [Metacello] Re: GitHub Sample project WTF?
|
| Overall, this is /very/ exciting. Thank you Dale for all this hard
| work!!!
|
| github's collaboration features alone have had Dale and I giddy,
| while we
| commented line-by-line via the web ui on changes I made. Issues can
| easily
| be linked to commits. And once a pull request is made to the main
| project,
| the pull request itself becomes the issue tracker. You can request a
| pull
| early, discuss the changes, and keep committing to that branch as the
| discussion progresses. See
| https://github.com/dalehenrich/metacello-work/pull/78 for an example
| of a
| conversation we had in a pull request, referencing (and linked to)
| specific
| lines from a commit, that led to additional commits. It's like
| Pharo's Slice
| concept... on steroids ;-)
|
|
| Dale Henrichs wrote
| >
| > The ConfigurationOfSample has versions 0.8 and 0.9, but when you
| > look at
| > the spec methods, you just see a #baseline: reference and no mcz
| > files.
| > WTF?
| >
| So I guess for each project, there'll be a branch-per-platform (e.g.
| pharo1dot4 branch, squeak4dot3 branch, etc.). I can't envision this
| clearly
| enough, but my gut says this could make maintaining cross-platform
| projects
| /much/ easier...

Yes there is good and bad ... I have been doing development on the FileTree project[1] with a branch per platform and there are certain things that are much easier.... The downside is that you have to use `cherry-pick` to share changes and it takes discipline to do commits that can be cleanly `cherry-picked`.

You can also pick off individual/files/methods but that is tricky too ...

The upside is that looking at the network view[2] of the project, you can get a good idea of the status of the particular branch you are interested in .. Like has the last code been ported to the squeak4.3 branch, yet...

[1] https://github.com/dalehenrich/filetree
[2] https://github.com/dalehenrich/filetree/network

| this was strange to me as well. I wouldn't mind the ConfigOfXXX
| package being part of the "normal" master branch (or other branches
| like stable, feature branches, etc) on a first impression. the
| reasons to split it out that I can think of are:
| - not affect commit versions of the project code by changes to the
| ConfigOfXXX
| - make it easier to distribute the ConfigOfXXX package on its own

Right on...

You are going to embed a SHA in the ConfigurationOf. You have to do the commit before you know what the SHA of the commit is, so the ConfigurationOf that is part of the commit will ALWAYS be wrong....it is just simpler to keep the ConfigurationOf on it's own branch...

Patrick,

You _CAN_ use a tag name in place of a SHA in the configuration.

There's a one-one correspondence between git tags and the commit SHA and for configurations there is a one to many relationship between the version number and the platform-specific SHA for each branch/platform.

Project maintainers can have a tag naming convention that makes sense (to them) when it comes to cross-platform versions  ...

The outside world would only care about "version 1.0.0" and be blissfully ignorant of the details of the "internal tag naming convention"

I agree that there are simpler ways to do the simple things, but I am looking for simple solutions to the hard things (for Smalltalk)... I think there are multiple solutions to many of these (and hopefully some that I haven't already looked at and discarded:) ...

This little discussion was the original point of my WTF post ... and I'm glad to explain my rationale, but I want to be clear that I am crying about some of these things, too and fell almost "forced into doing things a certain way" so I welcome creative ideas ... Hopefully though I've provided the groudwork for the scope of the problem ... "working in only Pharo or GemStone or Squeak" or "working for 75% of the projets" is not an option:)

I am looking forward to getting to the point ("Real Soon Now" TM) where other folks can start using git/github and metacello so that we can work out the "best practices"...

Dale

----- Original Message -----
| From: "Patrik Sundberg" <[hidden email]>
| To: [hidden email]
| Sent: Monday, July 23, 2012 12:06:52 PM
| Subject: Re: [Metacello] Re: GitHub Sample project WTF?
|
|
|
| | this was strange to me as well. I wouldn't mind the ConfigOfXXX
| | package being part of the "normal" master branch (or other branches
| | like stable, feature branches, etc) on a first impression. the
| | reasons to split it out that I can think of are:
| | - not affect commit versions of the project code by changes to the
| | ConfigOfXXX
| | - make it easier to distribute the ConfigOfXXX package on its own
|
| Right on...
|
| You are going to embed a SHA in the ConfigurationOf. You have to do
| the commit before you know what the SHA of the commit is, so the
| ConfigurationOf that is part of the commit will ALWAYS be
| wrong....it is just simpler to keep the ConfigurationOf on it's own
| branch...
|
|
|
|
| doh - that chicken-and-egg SHA problem should have been obvious. I
| never use SHA directly as it stands (i.e. with bundler in ruby or
| similar), just refer to branches and tags. I need to reread the
| material again but I'd think using branch or tag references would be
| preferred to SHA's if possible, right? Being able to use SHA's in
| special cases good, but branches or tags would probably be better
| choice in 90+% of cases, right?
|
|
| I do like the concept of having all the code related to a package,
| including "distribution" being available together but I can now see
| the issues better. Will think a bit more about it.
|
|
|
|

----- Original Message -----
| From: "Patrik Sundberg" <[hidden email]>
| To: [hidden email]
| Sent: Tuesday, July 24, 2012 1:44:35 AM
| Subject: Re: [Metacello] Re: GitHub Sample project WTF?
|
|
|
| On Monday, July 23, 2012 10:24:27 PM UTC+1, Dale wrote:
|
| Patrick,
|
| You _CAN_ use a tag name in place of a SHA in the configuration.
|
| There's a one-one correspondence between git tags and the commit SHA
| and for configurations there is a one to many relationship between
| the version number and the platform-specific SHA for each
| branch/platform.
|
| Project maintainers can have a tag naming convention that makes sense
| (to them) when it comes to cross-platform versions ...
|
| The outside world would only care about "version 1.0.0" and be
| blissfully ignorant of the details of the "internal tag naming
| convention"
|
| I agree that there are simpler ways to do the simple things, but I am
| looking for simple solutions to the hard things (for Smalltalk)... I
| think there are multiple solutions to many of these (and hopefully
| some that I haven't already looked at and discarded:) ...
|
| This little discussion was the original point of my WTF post ... and
| I'm glad to explain my rationale, but I want to be clear that I am
| crying about some of these things, too and fell almost "forced into
| doing things a certain way" so I welcome creative ideas ...
| Hopefully though I've provided the groudwork for the scope of the
| problem ... "working in only Pharo or GemStone or Squeak" or
| "working for 75% of the projets" is not an option:)
|
| I am looking forward to getting to the point ("Real Soon Now" TM)
| where other folks can start using git/github and metacello so that
| we can work out the "best practices"...
|
|
|
| Cool.
|
|
| In principle using tags (which doesn't affect SHA as I remember, just
| refer to a particular SHA) I guess one can at least in principle
| avoid the problem of unknown SHA's if including ConfigurationOfXXX
| in the master branch. Refer to tag in config, commit and then tag.
| So as long as using branches and tags it's doable, although I admit
| it's a tad icky and in a multi-platform setup using a branch by
| platform and a branch for config does sound like the right way to
| go.

Recommending that configurations be maintained on a separate branch isn't ideal, but it seems to be the only solution that is "caveat free" ...

|
|
|
| I'm a willing guinea pig and my current plan is to dive into
| smalltalk using pharo and metacello with git/github. I'll start
| trying it out this week most likely.
|
|
| Btw, what's the status around this work and pharo 2.0 ? I'm planing
| on using some of the 2.0 stuff and was going to dive in on the
| bleeding edge on both metacello/monticello and pharo - call me
| crazy..

If you are going to bleed, you might as well bleed big!

Your timing is very good:) I will be making a Preview release of metacello with the scripting api and git/github support so I will be very interested in having some early adopters beat on it.

As I mentioned in my previous post. I'll be testing the Metacello Preview on Pharo-2.0 starting today. I had some issues with using Pharo-2.0 earlier, but I believe that there have been bugfixes in the more recent vms.

The preview release should be ready in a day or two.

Dale

On Tuesday, July 24, 2012 10:40:31 AM UTC+1, Dale wrote:

----- Original Message -----
| Sent: Tuesday, July 24, 2012 1:44:35 AM
| Subject: Re: [Metacello] Re: GitHub Sample project WTF?
|
|
|
| On Monday, July 23, 2012 10:24:27 PM UTC+1, Dale wrote:
|
| Patrick,
|
| You _CAN_ use a tag name in place of a SHA in the configuration.
|
| There's a one-one correspondence between git tags and the commit SHA
| and for configurations there is a one to many relationship between
| the version number and the platform-specific SHA for each
| branch/platform.
|
| Project maintainers can have a tag naming convention that makes sense
| (to them) when it comes to cross-platform versions ...
|
| The outside world would only care about "version 1.0.0" and be
| blissfully ignorant of the details of the "internal tag naming
| convention"
|
| I agree that there are simpler ways to do the simple things, but I am
| looking for simple solutions to the hard things (for Smalltalk)... I
| think there are multiple solutions to many of these (and hopefully
| some that I haven't already looked at and discarded:) ...
|
| This little discussion was the original point of my WTF post ... and
| I'm glad to explain my rationale, but I want to be clear that I am
| crying about some of these things, too and fell almost "forced into
| doing things a certain way" so I welcome creative ideas ...
| Hopefully though I've provided the groudwork for the scope of the
| problem ... "working in only Pharo or GemStone or Squeak" or
| "working for 75% of the projets" is not an option:)
|
| I am looking forward to getting to the point ("Real Soon Now" TM)
| where other folks can start using git/github and metacello so that
| we can work out the "best practices"...
|
|
|
| Cool.
|
|
| In principle using tags (which doesn't affect SHA as I remember, just
| refer to a particular SHA) I guess one can at least in principle
| avoid the problem of unknown SHA's if including ConfigurationOfXXX
| in the master branch. Refer to tag in config, commit and then tag.
| So as long as using branches and tags it's doable, although I admit
| it's a tad icky and in a multi-platform setup using a branch by
| platform and a branch for config does sound like the right way to
| go.

Recommending that configurations be maintained on a separate branch isn't ideal, but it seems to be the only solution that is "caveat free" ...

|
|
|
| I'm a willing guinea pig and my current plan is to dive into
| smalltalk using pharo and metacello with git/github. I'll start
| trying it out this week most likely.
|
|
| Btw, what's the status around this work and pharo 2.0 ? I'm planing
| on using some of the 2.0 stuff and was going to dive in on the
| bleeding edge on both metacello/monticello and pharo - call me
| crazy..

If you are going to bleed, you might as well bleed big!

Your timing is very good:) I will be making a Preview release of metacello with the scripting api and git/github support so I will be very interested in having some early adopters beat on it.

As I mentioned in my previous post. I'll be testing the Metacello Preview on Pharo-2.0 starting today. I had some issues with using Pharo-2.0 earlier, but I believe that there have been bugfixes in the more recent vms.

The preview release should be ready in a day or two.

Patrik Sundberg wrote

Btw, what's the status around this work and pharo 2.0 ?

2.0 will be a huge release for Pharo. Many fundamental things are evolving and improving. 2.0 is usable, but many things have been breaking (and hopefully still more to come since each one ends in an improved system). Because of this, I've been splitting my time between 1.4 and 2.0 - using 2.0 for my "regular" work, but sticking with 1.4 for e.g. mission critical, deployed apps. If you're up for helping by identifying and possibly fixing issues, welcome and thank you. But know going in that this may distract you from your intended work.

Dale, will the preview work in Pharo 1.4?

On Tuesday, July 24, 2012 5:55:54 PM UTC+1, Sean DeNigris wrote:

Patrik Sundberg wrote
>
> Btw, what's the status around this work and pharo 2.0 ?
>

2.0 will be a /huge/ release for Pharo. Many fundamental things are evolving
and improving. 2.0 is usable, but many things have been breaking (and
hopefully still more to come since each one ends in an improved system).
Because of this, I've been splitting my time between 1.4 and 2.0 - using 2.0
for my "regular" work, but sticking with 1.4 for e.g. mission critical,
deployed apps. If you're up for helping by identifying and possibly fixing
issues, welcome and thank you. But know going in that this may distract you
from your intended work.

Patrik Sundberg wrote

object model familiar from ruby, but a lot of classes to learn

Cool! This is a very exciting time for Smalltalk (and Pharo in particular IMHO), so it should be great both for you and our community to have another pair of eyes/hands. I too came from the Ruby world not long ago. If any questions come up, let me know...

Sean

Sean,

The preview is working in Pharo-1.3, Pharo-1.4, Squeak4.3 and GLASS 1.0-beta.8.7.2.

Dale

----- Original Message -----
| From: "Sean P. DeNigris" <[hidden email]>
| To: [hidden email]
| Sent: Tuesday, July 24, 2012 9:55:54 AM
| Subject: [Metacello] Re: GitHub Sample project WTF?
|
|
| Patrik Sundberg wrote
| >
| > Btw, what's the status around this work and pharo 2.0 ?
| >
|
| 2.0 will be a /huge/ release for Pharo. Many fundamental things are
| evolving
| and improving. 2.0 is usable, but many things have been breaking (and
| hopefully still more to come since each one ends in an improved
| system).
| Because of this, I've been splitting my time between 1.4 and 2.0 -
| using 2.0
| for my "regular" work, but sticking with 1.4 for e.g. mission
| critical,
| deployed apps. If you're up for helping by identifying and possibly
| fixing
| issues, welcome and thank you. But know going in that this may
| distract you
| from your intended work.
|
| Dale, will the preview work in Pharo 1.4?
|
|
|
| --
| View this message in context:
| http://forum.world.st/GitHub-Sample-project-WTF-tp4635468p4641332.html
| Sent from the Metacello mailing list archive at Nabble.com.
|

Dale Henrichs wrote

The preview is working in Pharo-1.3, Pharo-1.4, Squeak4.3 and GLASS 1.0-beta.8.7.2.

Cool. I'm eagerly awaiting the preview release. I want to move my projects to gihub ASAP!!!

I did some more playing with this and have some more comments/questions below

On Tuesday, June 19, 2012 2:00:35 PM UTC+1, Dale wrote:

The Sample project was downloaded from GitHub without using the standard Monticello HTTP repository. Instead a zipfile of the repository contents is downloaded and unzipped into the git-cache directory (in parallel with package-cache). In the MonticelloBrowser you will see a number of github: repositories. WTF?

The ConfigurationOfSample has versions 0.8 and 0.9, but when you look at the spec methods, you just see a #baseline: reference and no mcz files. WTF?

The BaselineOfSample has a single baseline: method and it should look like a familiar baseline version spec, just in a separate class. WTF?

Git isn't involved for downloading and installing projects from GitHub. Curl and unzip are being used and are called using OSProcess. WTF?

Version 0.8 references a specific git commit and will not change ... so it's a lot like a traditional released version for a Metacello configuration...only the unchanging part is enforced by git.

Version 0.9 references the HEAD of the master branch...If you load version 0.9 (which is blessed as #development BTW) you will get the #bleedingEdge version of the project ...

ConfigurationOfSample is managed in the configuration branch of the Sample project[2]. The only package on the configuration branch is the ConfigurationOfSample. WTF?

BaselineOfSample is managed along with the rest of the packages in the master branch of the Sample project. It is embedded with packages and changes whenever new packages or projects or groups are added or removed ... otherwise it is left untouched.

Nowhere do you see fully qualified mcz file names...except in the MonticelloBrowser ... so mcz versions are being maintained, it's just that for a git/github project you don't have to constantly change them, like you do in a traditional Metacello project.

At the moment, the MetacelloPreview is functional, but only the `load` command has been fleshed out. Not looking for scripting API WTF, but if you've got some ... fire away:)

Scratch your head, wrap your brain around the concept of BaselineOf, ask questions, yell, now is a good time:)

The Sample project is the future of Metacello...

comments embedded...

----- Original Message -----
| From: "Patrik Sundberg" <[hidden email]>
| To: [hidden email]
| Sent: Tuesday, July 24, 2012 3:18:02 PM
| Subject: [Metacello] Re: GitHub Sample project WTF?
|
| I did some more playing with this and have some more
| comments/questions below
|
| On Tuesday, June 19, 2012 2:00:35 PM UTC+1, Dale wrote:
|
| The Sample project was downloaded from GitHub without using the
| standard Monticello HTTP repository. Instead a zipfile of the
| repository contents is downloaded and unzipped into the git-cache
| directory (in parallel with package-cache). In the MonticelloBrowser
| you will see a number of github: repositories. WTF?
|
|
|
|
| I see the directory is called github-cache in my local setup after
| running the commands - I like git-cache better since I for example
| maintain some private projects in my own repo (fronted by gitlab,
| great project if you haven't seen it).

The github-cache is only used to cache downloads from github. Metacello doesn't automatically clone projects from github (right now). For cloned git projects you would use a filetree repository and the clone can be located anywhere on disk.

|
|
| The other thing I don't quite get is the "intermediate" directory at
| the end called something like:
| xxx/github-cache/dalehenrich/sample/cc46e15368c6b7cf3667427faaf6167d35044f78/dalehenrich-sample-cc46e15
|
|
| I get all the bits up to the last part - why is that last part needed
| and what does it signify?

The things in the github cache are downloads of the zipped contents of the directories, not cloned git repositories. The 'dalehenrich/sample/cc46e15368c6b7cf3667427faaf6167d35044f78' part of the path comes directly from the repository spec from the project reference in the configuration. The 'dalehenrich-sample-cc46e15' is the root directory in the zip archive ...

|
|
| A scheme for making it more generic would be:
| xxx/git-cache/URI/branch|tag|SHA/the_part_i_dont_yet_get (if the last
| part is needed)
|
|
| the URI would be e.g:
| http://github.com/sundbp/reponame.git
| https://github.com/sundbp/reponame.git
| git://github.com/sundbp/reponame.git
| [hidden email]:sundbp/reponame.git
|
|
| Obviously to include it in the filename we'd need to encode it to be
| a valid filename somehow. I do think that being future proof is
| worth it and then thinking in general git URI's makes sense. Also,
| it may be worth taking a look at how bundler organizes it's git
| cache (given it's relying on git for fetching etc and it'd be good
| to go that way later even if just supporting http get for now).

Since I'm not that familiar with Bundler...Does bundler automatically clone git repositories from github?

For the Smalltalk community at the moment, I can't demand that folks install git on their computers. I'm trying to make the barrier to using git/github as low as possible.

I want the use of github repositories to be transparent to folks who are simply consuming the bits from a project and zip downloads give me that.

If a developer is going to do development on a project, then it makes sense to require git (but with Monticello even git wouldn't be required).

There is work ongoing with providing an in-mage interface to git/github and I anticipate that when that is released we'll be able to support direct git manipulation from image-based tools.

|
|
|
| The ConfigurationOfSample has versions 0.8 and 0.9, but when you look
| at the spec methods, you just see a #baseline: reference and no mcz
| files. WTF?
|
|
|
|
| So the branch|tag|SHA is given in the repository string. It'd
| probably be sweeter to have #branch, #tag, #sha messages explicitly
| and the repository is used to just point to the git repository,
| that'd be the more natural way to specify it with git, and that way
| we can have the baseline specify the repo, with the versions
| specifying the branch|tag|SHA.

I understand what you're getting at, but we're not talking about directly monkeying with git versions right now. Remember the github repository reference is a download of the directory structure for a particular branch|tag|sha. It's pretty static on disk so a static string is appropriate.

When and if we start auto-cloning git repositories, then I will agree that providing separate messages will make sense.

 
|
| I have not thought about how that integrates with non-git repos in
| the above, just what the natural git way of doing it would be. It
| may not mesh well with non-git.

Yes, the current github: specification is a non-git repos.

|
|
| The BaselineOfSample has a single baseline: method and it should look
| like a familiar baseline version spec, just in a separate class.
| WTF?
|
|
|
|
| no surprises to me.
|
|
|
| Git isn't involved for downloading and installing projects from
| GitHub. Curl and unzip are being used and are called using
| OSProcess. WTF?
|
|
|
|
| As noted above, I'd vote for making the underlying naming etc more
| general to be future proof, but for now just support github and
| http/https that we can do without using git at all and just fail for
| any other case for now. However, laying the groundwork will pay off
| the day we want to have complete two-way support to also push from
| within the image using git+ssh etc (having the git-cache holding
| "real" git repo clones).

As for future proofing I expect that the specification for git repository will different (in some way) and the current convention will always mean "download the bits for that SHA".

|
|
| Version 0.8 references a specific git commit and will not change ...
| so it's a lot like a traditional released version for a Metacello
| configuration...only the unchanging part is enforced by git.
|
|
|
| Logical, my only input is the above regarding separating repo and
| version (in the general sense of branch|tag|SHA) if possible.
|
|
| Version 0.9 references the HEAD of the master branch...If you load
| version 0.9 (which is blessed as #development BTW) you will get the
| #bleedingEdge version of the project ...
|
| ConfigurationOfSample is managed in the configuration branch of the
| Sample project[2]. The only package on the configuration branch is
| the ConfigurationOfSample. WTF?
|
|
|
|
| We talked about this elsewhere, I'm pretty comfy with it being in a
| separate branch having chewed on it a bit.
|
|
| Drawing some inspiration from bundler again I guess the way it works
| there is the packages of the project itself are implicitly the same
| as that of the checked out bundle file. Drawing an analogy would be
| to have the ConfigOfXXX in the normal branch, but implicitly use the
| same version as the ConfigOfXXX for the project's own packages. That
| however doesn't jive with the metacello layer on top of the git
| layer, so I think you're right a separate config branch is the
| natural place to put it.
|
|
| BaselineOfSample is managed along with the rest of the packages in
| the master branch of the Sample project. It is embedded with
| packages and changes whenever new packages or projects or groups are
| added or removed ... otherwise it is left untouched.
|
|
|
|
|
| I could go either way on this one. No issues with that one in the
| same way as ConfigOf and could be kept in the project branch(es). It
| could also go in the config branch. If in the project branches then
| we can have for example a pharo2.0.x branch with a different
| baseline spec than gemstone branch, but both pinned down by the same
| ConfigOf. However, could also use the inbuilt metacello features for
| managing the platform specific stuff, and then I'm more thinking it
| goes with the ConfigOf in the configuration branch to group all
| version and package management info in one branch.

The BaselineOf really needs to be embedded with the rest of the packages ... if a new package is added or removed, or there is a new dependency in a particular version of the project then the BaselineOf must be changed in the same git commit as the other changes since the two must be in sync ... The BaselineOf is the equivalent of a makefile (do you have these in ruby?) and it is tightly coupled to the files present in the project, so it doesn't make sense to put the BaselineOf in a separate branch.

The ConfigurationOf has to be in a separate branch because it is the meta layer over the platform branches.

|
|
| How does that reasoning stack up with yours?
|
|
|
| Nowhere do you see fully qualified mcz file names...except in the
| MonticelloBrowser ... so mcz versions are being maintained, it's
| just that for a git/github project you don't have to constantly
| change them, like you do in a traditional Metacello project.
|
| At the moment, the MetacelloPreview is functional, but only the
| `load` command has been fleshed out. Not looking for scripting API
| WTF, but if you've got some ... fire away:)
|
| Scratch your head, wrap your brain around the concept of BaselineOf,
| ask questions, yell, now is a good time:)
|
| The Sample project is the future of Metacello...
|
|
|
|
| Indeed - I see a lot of things I like here!
|
|
| Let me know if there are specific things you want tried out or
| otherwise looked at.

I am looking forward to more of your feedback ... I think that moving forward we need to gain experience using Metacello/git/github in real work scenarios ...

Currently I am accommodating git without embracing it, because I think that trying to include git in this round would be biting off more than we can chew.

Dale

On Wednesday, July 25, 2012 4:33:22 PM UTC+1, Dale wrote:

comments embedded...

----- Original Message -----
| To: [hidden email]
| Sent: Tuesday, July 24, 2012 3:18:02 PM
| Subject: [Metacello] Re: GitHub Sample project WTF?
|
| I did some more playing with this and have some more
| comments/questions below
|
| On Tuesday, June 19, 2012 2:00:35 PM UTC+1, Dale wrote:
|
| The Sample project was downloaded from GitHub without using the
| standard Monticello HTTP repository. Instead a zipfile of the
| repository contents is downloaded and unzipped into the git-cache
| directory (in parallel with package-cache). In the MonticelloBrowser
| you will see a number of github: repositories. WTF?
|
|
|
|
| I see the directory is called github-cache in my local setup after
| running the commands - I like git-cache better since I for example
| maintain some private projects in my own repo (fronted by gitlab,
| great project if you haven't seen it).

The github-cache is only used to cache downloads from github. Metacello doesn't automatically clone projects from github (right now). For cloned git projects you would use a filetree repository and the clone can be located anywhere on disk.

| The other thing I don't quite get is the "intermediate" directory at
| the end called something like:
| xxx/github-cache/dalehenrich/sample/cc46e15368c6b7cf3667427faaf6167d35044f78/dalehenrich-sample-cc46e15
|
|
| I get all the bits up to the last part - why is that last part needed
| and what does it signify?

The things in the github cache are downloads of the zipped contents of the directories, not cloned git repositories. The 'dalehenrich/sample/cc46e15368c6b7cf3667427faaf6167d35044f78' part of the path comes directly from the repository spec from the project reference in the configuration. The 'dalehenrich-sample-cc46e15' is the root directory in the zip archive ...

|
| A scheme for making it more generic would be:
| xxx/git-cache/URI/branch|tag|SHA/the_part_i_dont_yet_get (if the last
| part is needed)
|
|
| the URI would be e.g:
| http://github.com/sundbp/reponame.git
| https://github.com/sundbp/reponame.git
| git://github.com/sundbp/reponame.git
| [hidden email]:sundbp/reponame.git
|
|
| Obviously to include it in the filename we'd need to encode it to be
| a valid filename somehow. I do think that being future proof is
| worth it and then thinking in general git URI's makes sense. Also,
| it may be worth taking a look at how bundler organizes it's git
| cache (given it's relying on git for fetching etc and it'd be good
| to go that way later even if just supporting http get for now).

Since I'm not that familiar with Bundler...Does bundler automatically clone git repositories from github?

For the Smalltalk community at the moment, I can't demand that folks install git on their computers. I'm trying to make the barrier to using git/github as low as possible.

I want the use of github repositories to be transparent to folks who are simply consuming the bits from a project and zip downloads give me that.

If a developer is going to do development on a project, then it makes sense to require git (but with Monticello even git wouldn't be required).

There is work ongoing with providing an in-mage interface to git/github and I anticipate that when that is released we'll be able to support direct git manipulation from image-based tools.

|
| The ConfigurationOfSample has versions 0.8 and 0.9, but when you look
| at the spec methods, you just see a #baseline: reference and no mcz
| files. WTF?
|
|
|
|
| So the branch|tag|SHA is given in the repository string. It'd
| probably be sweeter to have #branch, #tag, #sha messages explicitly
| and the repository is used to just point to the git repository,
| that'd be the more natural way to specify it with git, and that way
| we can have the baseline specify the repo, with the versions
| specifying the branch|tag|SHA.

I understand what you're getting at, but we're not talking about directly monkeying with git versions right now. Remember the github repository reference is a download of the directory structure for a particular branch|tag|sha. It's pretty static on disk so a static string is appropriate.

When and if we start auto-cloning git repositories, then I will agree that providing separate messages will make sense.

| I have not thought about how that integrates with non-git repos in
| the above, just what the natural git way of doing it would be. It
| may not mesh well with non-git.

Yes, the current github: specification is a non-git repos.

| The BaselineOfSample has a single baseline: method and it should look
| like a familiar baseline version spec, just in a separate class.
| WTF?
|
|
|
|
| no surprises to me.
|
|
|
| Git isn't involved for downloading and installing projects from
| GitHub. Curl and unzip are being used and are called using
| OSProcess. WTF?
|
|
|
|
| As noted above, I'd vote for making the underlying naming etc more
| general to be future proof, but for now just support github and
| http/https that we can do without using git at all and just fail for
| any other case for now. However, laying the groundwork will pay off
| the day we want to have complete two-way support to also push from
| within the image using git+ssh etc (having the git-cache holding
| "real" git repo clones).

As for future proofing I expect that the specification for git repository will different (in some way) and the current convention will always mean "download the bits for that SHA".

| Version 0.8 references a specific git commit and will not change ...
| so it's a lot like a traditional released version for a Metacello
| configuration...only the unchanging part is enforced by git.
|
|
|
| Logical, my only input is the above regarding separating repo and
| version (in the general sense of branch|tag|SHA) if possible.
|
|
| Version 0.9 references the HEAD of the master branch...If you load
| version 0.9 (which is blessed as #development BTW) you will get the
| #bleedingEdge version of the project ...
|
| ConfigurationOfSample is managed in the configuration branch of the
| Sample project[2]. The only package on the configuration branch is
| the ConfigurationOfSample. WTF?
|
|
|
|
| We talked about this elsewhere, I'm pretty comfy with it being in a
| separate branch having chewed on it a bit.
|
|
| Drawing some inspiration from bundler again I guess the way it works
| there is the packages of the project itself are implicitly the same
| as that of the checked out bundle file. Drawing an analogy would be
| to have the ConfigOfXXX in the normal branch, but implicitly use the
| same version as the ConfigOfXXX for the project's own packages. That
| however doesn't jive with the metacello layer on top of the git
| layer, so I think you're right a separate config branch is the
| natural place to put it.
|
|
| BaselineOfSample is managed along with the rest of the packages in
| the master branch of the Sample project. It is embedded with
| packages and changes whenever new packages or projects or groups are
| added or removed ... otherwise it is left untouched.
|
|
|
|
|
| I could go either way on this one. No issues with that one in the
| same way as ConfigOf and could be kept in the project branch(es). It
| could also go in the config branch. If in the project branches then
| we can have for example a pharo2.0.x branch with a different
| baseline spec than gemstone branch, but both pinned down by the same
| ConfigOf. However, could also use the inbuilt metacello features for
| managing the platform specific stuff, and then I'm more thinking it
| goes with the ConfigOf in the configuration branch to group all
| version and package management info in one branch.

The BaselineOf really needs to be embedded with the rest of the packages ... if a new package is added or removed, or there is a new dependency in a particular version of the project then the BaselineOf must be changed in the same git commit as the other changes since the two must be in sync ... The BaselineOf is the equivalent of a makefile (do you have these in ruby?) and it is tightly coupled to the files present in the project, so it doesn't make sense to put the BaselineOf in a separate branch.

The ConfigurationOf has to be in a separate branch because it is the meta layer over the platform branches.

|
|
| How does that reasoning stack up with yours?
|
|
|
| Nowhere do you see fully qualified mcz file names...except in the
| MonticelloBrowser ... so mcz versions are being maintained, it's
| just that for a git/github project you don't have to constantly
| change them, like you do in a traditional Metacello project.
|
| At the moment, the MetacelloPreview is functional, but only the
| `load` command has been fleshed out. Not looking for scripting API
| WTF, but if you've got some ... fire away:)
|
| Scratch your head, wrap your brain around the concept of BaselineOf,
| ask questions, yell, now is a good time:)
|
| The Sample project is the future of Metacello...
|
|
|
|
| Indeed - I see a lot of things I like here!
|
|
| Let me know if there are specific things you want tried out or
| otherwise looked at.

I am looking forward to more of your feedback ... I think that moving forward we need to gain experience using Metacello/git/github in real work scenarios ...

Currently I am accommodating git without embracing it, because I think that trying to include git in this round would be biting off more than we can chew.

Patrik Sundberg wrote

My first dive into 2.0 and metacello didn't go so well, the metacello
bootstrap is broken and I got frustrated

I'm not sure what's wrong with it. For the time-being, if you load Metacello a little more explicitly it should work. Before loading any Metacello configs, try:
    Gofer it
        url: 'http://seaside.gemstone.com/ss/metacello';
        package: 'ConfigurationOfMetacello';
        load.
       
(Smalltalk at: #ConfigurationOfMetacello) project stableVersion load: 'batch'.

Patrik Sundberg wrote

My first dive into 2.0 and metacello didn't go so well, the metacello
bootstrap is broken and I got frustrated

Oh, b.t.w. All the energy is great. Please keep pushing!!