GitHub Sample project WTF?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

GitHub Sample project WTF?

Dale Henrichs
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
Reply | Threaded
Open this post in threaded view
|

Re: GitHub Sample project WTF?

Sean P. DeNigris
Administrator
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
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: GitHub Sample project WTF?

Patrik Sundberg


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


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

is there more to it?

Patrik

Reply | Threaded
Open this post in threaded view
|

Re: GitHub Sample project WTF?

Dale Henrichs
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
Reply | Threaded
Open this post in threaded view
|

Re: GitHub Sample project WTF?

Dale Henrichs
In reply to this post by Sean P. DeNigris


----- 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
Reply | Threaded
Open this post in threaded view
|

Re: GitHub Sample project WTF?

Patrik Sundberg
In reply to this post by Dale Henrichs
| 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.


Reply | Threaded
Open this post in threaded view
|

Re: GitHub Sample project WTF?

Dale Henrichs
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.
|
|
|
|
Reply | Threaded
Open this post in threaded view
|

Re: GitHub Sample project WTF?

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

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

Thanks
Reply | Threaded
Open this post in threaded view
|

Re: GitHub Sample project WTF?

Dale Henrichs

----- 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
Reply | Threaded
Open this post in threaded view
|

Re: GitHub Sample project WTF?

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


Sweet, I'll keep an eye out and report how I get on with the preview.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub Sample project WTF?

Sean P. DeNigris
Administrator
In reply to this post by Patrik Sundberg
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?
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: GitHub Sample project WTF?

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

Thanks for the warning. I do realize it'll be an uphill battle and I may be biting off more than I can chew given I'm essentially learning the whole system as I go along (done a lot of languages before but not smalltalk. object model familiar from ruby, but a lot of classes to learn). That kind of stuff hasn't stopped me from trying in the past :) Learning the system via 2.0 sounds preferable to 1.4, so I have a feeling it'll either turn out to be a great way to pick it up or a disaster since too many intricate issues can pop up. We shall see.

Reply | Threaded
Open this post in threaded view
|

Re: GitHub Sample project WTF?

Sean P. DeNigris
Administrator
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
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: GitHub Sample project WTF?

Dale Henrichs
In reply to this post by Sean P. DeNigris
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.
|
Reply | Threaded
Open this post in threaded view
|

Re: GitHub Sample project WTF?

Sean P. DeNigris
Administrator
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!!!
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: GitHub Sample project WTF?

Patrik Sundberg
In reply to this post by Dale Henrichs
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 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?

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

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

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.

Patrik
 
Reply | Threaded
Open this post in threaded view
|

Re: GitHub Sample project WTF?

Dale Henrichs
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
Reply | Threaded
Open this post in threaded view
|

Re: GitHub Sample project WTF?

Patrik Sundberg
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 short version of my point was more that it seems unnecessary to special case github. Why not include it in a more general scheme so that any provider supporting the same API can be used, i.e. gitlab is a way to run your own private github so to say and it is (mostly) API compatible.
 
| 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 ...


I understand that today these are just "plain" files transferred via the github API's ability to throw a zip together for a specific revision. However, I don't see why we'd need to limit us to that special case of file transfer in terms of how things are layed out and named etc. My thinking was to make it a bit less special case in terms of design of layout etc, but for now just support the specific file transfer case.

So in that line of thinking it seems unnecessary to me to have that last "zip file random bit" in the path. A little bit more generic conventions and it'll be future proof for working with general git repos and transfer methods via proper URI's.

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


Yes. The ruby community uses nothing but git for most things they can. 

The corresponding terms as I see it are:

ruby - pharo
rubygem - monticello package
bundler Gemfile - metacello config
bundler - metacello
git - git

In some ways metacello is more powerful in building the graph of dependencies relying on other metacello configs, bundler can only rely on gems, not other bundles (although gems have dependency info as well). But bundler is more mature in terms of integrating with rubygems living in git repos and other such things.

I just checked and what bundler does is clone git repos (from anywhere via any protocol (http, https, git, ssh), not just github) into a "bundler" directory in the normal rubygems cache directory structure. inside there is creates versions like "rubygemname-shortSHA", so a very flat structure relying only on SHA and not involving the repo URL. I guess that's enough since it'll be unique. So if you depend on say the rubygem foo located in the "stable" branch of a specified git repo, it'll go and ask the repo what the latest revision on stable is, get the SHA, create a directory for that named for example "foo-5f9317f0f789" and clone the repo on that revision in there, and in the bundle we're with it'll lock the foo gem to that location. If another bundle relies on a different revision it'll lock to a different dir for that (I guess the various bundles can be thought of analogous to images, i.e. things are specified and loaded with dependencies in a consistent way per bundle (i.e. a running process has a 1-to-1 mapping with a bundle, which is why metacello and bundler aren't quite the same since a bundle can't rely on other bundles).

Given that I'd revise what I wrote above to simpler URI's involving just repo name and SHA. The SHA would be good enough - and if later we have real repos the repo itself knows all meta info about itself so no use having it in the naming conventions. Based on that I'd suggest instead making:

xxx/github-cache/dalehenrich/sample/cc46e15368c6b7cf3667427faaf6167d35044f78/dalehenrich-sample-cc46e15 

into:

xxx/git-cache/sample/cc46e15368c6b7cf3667427faaf6167d35044f78/  (and in there is the plain files for now, at some point could be a git repo).

btw, bundler just shells out to use the normal git installation of the machine it's running on - no native ruby implementation of git protocols etc, no need to when the command line tool gives you all you need + you get things like config etc consistent across all useage of git. and reusability, if git adds a new transfer protocol or storage format then no need to update anything, just continue use the git command as usual. So the same way you currently do a curl and zip you could do a git fetch/clone. I'm not saying it makes sense to focus on that, just pointing out how in principle one can start migrating at some point.

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 agree with that - since I'm very comfortable with git/github my point is more to not lock into conventions based on the special case of zip file transfer only. If possible let's use conventions that are less special case.
 
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.


Yes, right approach. Just being able to follow projects on gits will make it so much easier for people to participate in a lazy way.
 
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.


Yep, at some point having a 2-way workflow would be sweet. It's not clear how one would go about it to me yet - given that one usually have 1 active part of a project, which one wants 2way activity on, and several dependencies that are passive and where one would only ever read. That's a later question to crack though.

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


Fair enough - however it sounds like at that stage one would need to update the URI structure completely. I guess if one keeps github://xxx for the current scheme and uses the more general git://xxx in the future that's no harm. Only bit I can think of is that it could be nice to keep githuib:// for the general case (as a shortcut) and use a variation for the special case of now, perhaps github-zip:// or something like that?


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


Get that, trying to think of ways where it wont interfere or cause problems when they could be 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".


yes - but may be worth saving the really nice names and conventions for the more general case.
  
| 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.


Ah, I see your thinking. I guess trying to make every git commit always consistent in principle is a worthy goal. I was implicitly assuming a 2 commit step - thanks for pointing it out more clearly.

No makefiles in ruby, the same kind of meta info comes from the rubygem spec or bundler Gemfile depending on the setting. And yes, one would commit a change where the rubygem in development depends on another gem by updating the gemspec at the same time as the code using it. Which is why initially it felt wrong on gut feel to have the ConfigOf on the outside. The same issue of ConfigOf never arises in the ruby/bundler parallel. I'll contrast that a bit more in detail once I've thought it true.

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


Btw, do you have it written down somewhere how your current workflow looks form the developer side? (not jsut consider of things from git/github but publishing to as well). I'd be interested to know.

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.


My head is fully embraced for several years so I'm bound to think more aggressively about it :)

P.S. My first dive into 2.0 and metacello didn't go so well, the metacello bootstrap is broken and I got frustrated about the combination of lack of  knowledge to effectively dig into it, and lack of across-build diff availability to make it easier to find the starting point (Sean seemed to have narrowed it down in another thread but without image-wide-diff I'm not sure how to start digging further..

Reply | Threaded
Open this post in threaded view
|

Re: GitHub Sample project WTF?

Sean P. DeNigris
Administrator
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'.
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: GitHub Sample project WTF?

Sean P. DeNigris
Administrator
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!!
Cheers,
Sean
12