Better support for loading code from a tag

[npasserini]

Loading

  repository: 'github://pharo-nosql/voyage/mc';
  baseline: 'Voyage';
  load: 'mongo tests'.

will produce a repository (mongotalk) pointing to a tag, which poses a few problems:

1. Branch is named "no branch", should show the name for the tag.
2. It shows outgoing commits that shouldn't be there.
3. It produces an error if you go to the push section.

[dalehenrich]

@npasserini ... why are you missing a branch here ... the semantics for that url github://pharo-nosql/voyage/mc is to access the master branch by default ... that's what Metacello does when it creates the zipball ... by default ... BTW, why are you changing the semantics of the github url from download as zipball to clone -- assuming that this is what you are doing?

I understand the why, I am porting Metacello and Cypress to the base of GemStone ... I have thought of overloading github:// urls like you are apparently doing and i have also thought of using @ThierryGoubier gitfiletree:// url --- I like the way that @ThierryGoubier designed the url ... right now I am using gitfiletree:// and gitcypress:// (take at look at these tests ) ...

My work with Cypress is in the experimental stages as is yours, so now is a good time to have a conversation and come up with an approach that makes sense ...

[npasserini]

@dalehenrich I am not missing a branch, it is just that when Iceberg cloned and checked out a tag, git returns "no branch" as current branch and Iceberg was not handling this situation properly. I do not think that it has a specific relationship to Metacello, it is more likely the way we have to easily reproducer the error because it was the way we found it.

[npasserini]

I do not want to change the semantics, I just want to provide another
implementation of the github url. It is optional, you can turn it off if
you do not want that.

I also plan to add a specific iceberg:// url, but for easying the
migration, we've agreed that it could be useful to be able to handle github
urls also.

What do you think?

I am always interesting in sharing our experiences, just let me know when
and how!

2016-10-25 15:33 GMT+02:00 Dale Henrichs [email protected]:

@npasserini https://github.com/npasserini ... why are you missing a
branch here ... the semantics for that url github://pharo-nosql/voyage/mc
is to access the master branch by default ... that's what Metacello does
when it creates the zipball ... by default ... BTW, why are you changing
the semantics of the github url from download as zipball to clone --
assuming that this is what you are doing?

I understand the why, I am porting Metacello and Cypress to the base of
GemStone ... I have thought of overloading github:// urls like you are
apparently doing and i have also thought of using @ThierryGoubier
https://github.com/ThierryGoubier gitfiletree:// url --- I like the way
that @ThierryGoubier https://github.com/ThierryGoubier designed the url
... right now I am using gitfiletree:// and gitcypress:// (take at look
at these tests
https://github.com/dalehenrich/CypressReferenceImplementation/tree/portability/cypress/Cypress-Tests.package/CypressPackageManagerTest.class/instance
) ...

My work with Cypress is in the experimental stages as is yours, so now is
a good time to have a conversation and come up with an approach that makes
sense ...

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#191 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEa1OVuMkvpGZO0NYiC-EcBdEMSR9Ixzks5q3gUvgaJpZM4KdSWB
.

[dalehenrich]

On 10/25/16 11:23 AM, Nico Passerini wrote:

I do not want to change the semantics, I just want to provide another
implementation of the github url. It is optional, you can turn it off if
you do not want that.

I also plan to add a specific iceberg:// url, but for easying the
migration, we've agreed that it could be useful to be able to handle
github
urls also.

What do you think?

I am always interesting in sharing our experiences, just let me know when
and how!
I think that this is exactly what we should talk about next week when
you are back from holiday ... I think that together we can come up with
a solution ... as I mention in a comment on #168, now is a good time to
work together on defining what we should do about the urls for Metacello
repositories going forward ... I really like what @ThierryGoubier did
with the gitfiletree: url pattern, but I think we need to talk about
how iceberg and gitfiletree and cypress can all use the same url to
possibly mean separate things ...

The filtree repo is the common denominator, but I think that
gitfiletree: is already tied to the GitFileTree tool --- but other
than performing the clone, I am not sure that there is too tight of a
coupling ...

I also want to understand more about why you think and iceberg: url is
needed ...

... resolving may mean that we will need to @marceltaeumel
(https://github.com/hpi-swa/metacello-git), @ThierryGoubier,
@martinmcclure, you and myself in a skype conversation to talk about the
different needs and dynamics ...

I want an url that can be embedded in BaselineOf to reference another
project that has the same semantics on all platforms:

• clone the repository to the local disk if possible, download
  zipball if possible, fail

and I want that url to be able to reference git repositories on gitlab,
github, bitbucket, etc. ... for all platforms that use Metacello:
GemStone, Squeak, Pharo, GemStone base, etc.

Dale

[npasserini]

Fixed in 24a078b

[npasserini]

That sounds great.

2016-10-25 20:58 GMT+02:00 Dale Henrichs [email protected]:

On 10/25/16 11:23 AM, Nico Passerini wrote:

I do not want to change the semantics, I just want to provide another
implementation of the github url. It is optional, you can turn it off if
you do not want that.

I also plan to add a specific iceberg:// url, but for easying the
migration, we've agreed that it could be useful to be able to handle
github
urls also.

What do you think?

I am always interesting in sharing our experiences, just let me know when
and how!
I think that this is exactly what we should talk about next week when
you are back from holiday ... I think that together we can come up with
a solution ... as I mention in a comment on #168, now is a good time to
work together on defining what we should do about the urls for Metacello
repositories going forward ... I really like what @ThierryGoubier did
with the gitfiletree: url pattern, but I think we need to talk about
how iceberg and gitfiletree and cypress can all use the same url to
possibly mean separate things ...

The filtree repo is the common denominator, but I think that
gitfiletree: is already tied to the GitFileTree tool --- but other
than performing the clone, I am not sure that there is too tight of a
coupling ...

I also want to understand more about why you think and iceberg: url is
needed ...

... resolving may mean that we will need to @ marceltaeumel
(https://github.com/hpi-swa/metacello-git), @ThierryGoubier,
@martinmcclure, you and myself in a skype conversation to talk about the
different needs and dynamics ...

I want an url that can be embedded in BaselineOf to reference another
project that has the same semantics on all platforms:

• clone the repository to the local disk if possible, download
  zipball if possible, fail

and I want that url to be able to reference git repositories on gitlab,
github, bitbucket, etc. ... for all platforms that use Metacello:
GemStone, Squeak, Pharo, GemStone base, etc.

Dale

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#191 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEa1OY_MYwmBpt1Bi3pZfVfO39F_xYJiks5q3lE9gaJpZM4KdSWB
.

[dalehenrich]

Talking with @martinmcclure, it seems that we could use the scheme git: with the same components as those defines by @ThierryGoubier for gitfiletree: to mean "clone from project hosted on hostname if you can or download zip if you can and create a filetree repo in image" ... this retains the very nice semantics of gitfiletree: without breaking GitFiletree itself, since that url is tied to a specific repository implementation ... it also opens the door for supporting svn:, hg:, etc. ... But we'll talk more next week.

[npasserini]

Ok, two questions, maybe related to each other:

1. What would you use to clone a repository?
   Of course I would propose Iceberg, but in any case, we need some
   implementation that does not depend in os(sub)process.

2. If you do not use Iceberg, is there an event I can listen to, so to
   create an Iceberg repository after you cloned and loaded the code?

2016-10-26 19:13 GMT+02:00 Dale Henrichs [email protected]:

Talking with @martinmcclure https://github.com/martinmcclure, it seems
that we could use the scheme git: with the same components as those
defines by @ThierryGoubier https://github.com/ThierryGoubier for
gitfiletree: to mean "clone from project hosted on hostname if you can or
download zip if you can and create a filetree repo in image" ... this
retains the very nice semantics of gitfiletree: without breaking
GitFiletree itself, since that url is tied to a specific repository
implementation ... it also opens the door for supporting svn:, hg:, etc.
... But we'll talk more next week.

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
#191 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEa1OfofkEnv4lKt9cOI4sMofiAwCNqzks5q34oogaJpZM4KdSWB
.

[dalehenrich]

On 10/26/16 1:08 PM, Nico Passerini wrote:

Ok, two questions, maybe related to each other:

1. What would you use to clone a repository?
   Of course I would propose Iceberg, but in any case, we need some
   implementation that does not depend in os(sub)process.
   Well, this is one of the reasons that I use the phrase "if you can" ...
   this is very platform specific and because git is involved it means that
   git (or libgit2) has to be available ... My inclination is to have a
   platform-specific "plugin" for Metacello that does the clone and falls
   back to "standard" github: behavior ... Metacello already has a
   platform-specific object (MetacelloPlatform current) where the
   platform-specific plugin would be installed and Metacello would then
   have a fall-back zip download call implement in the common
   MetacelloPlaform class ...

For Pharo6.0 the iceberg could be the default for doing the git clone,
while in pharo5.0 and pharo4.0 gitfiletree would be the default ... if
installed ...

2. If you do not use Iceberg, is there an event I can listen to, so to
   create an Iceberg repository after you cloned and loaded the code?
   I would prefer to make an API the Metacello uses to do the resolution
   and allow each platform to make the decisions as to how the clone is
   done and how it is managed in the image ... as long as we end up with
   FileTree/Cypress compatible API for the repository, Metacello should be
   happy ...

I would prefer for Metacello to not provide a standard clone
implementation ... it has been hard enough to maintain the zip download
code without adding git dependence into the mix:)

As part of my gs_port work in Metacello I may do a refactoring of the
platform hiearchy and clean up some cruft that has accumulated over the
years there ... and that will be an opportunity to add additional
protocol along with support for the git: scheme ...

Today, the gs_port branch of Metacello is not functional on Squeak or
Pharo and when I get back from Smalltalks I've got some commitments for
other projects besides Metacello that I will have to work through, so I
may not be getting back to the Metacello gs_port work until the new year
...

However, in the meantime we can perhaps work out something that can work
in the interim so that your work isn't affected ...