Metacello with Git

Le 19/12/2017 à 19:25, Vitor Medina Cruz a écrit :
> Hello,
>
> Using github://<github_path>/<srcpath> metacello works fine, but is
> there another more general way of refering to a remote git repo? From
> BitBucket or Gitlab for example.
>

Hi,

For bitbucket you can use bitbucket://.
I don't know for gitlab.

Anyway, we are talking about the possibility to use custom URLs that
would also allow to depend on a git repository from a private server.

See discussion at: https://github.com/Metacello/metacello/issues/474

> Regards,
> Vitor


--
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France

BitBucket is supported with like Github with:
butbucket://<butbucket_path>/<srcpath>.

With regards to GitLab, their download zip format is/was different
enough from BitBucket/Github to make it difficult to provide the same
level of support. See the series of comments here[1].

When the github:// was first introduced it was done in such a way that
users of projects on GitHub did not have to have git installed on their
local computers ... it was a way to make it possible for folks to begin
using git without requiring everyone to install git ...

These days, we are getting to the point where I am beginning to flip the
question on it's head and begin thinking that it should be possible for 
a developer to choose to have have the github:// url interpreted as
"create a local clone of the remote repository" instead of "download a
tarball of the remote repository" . With this approach it should be
possible to include gitlab url support as well since the gitlab issue is
related to the specific handling of repository tarballs...

... there are current discussions in this area on these two issues [2]
and [3].

Dale

[1] https://github.com/Metacello/metacello/issues/287#issuecomment-59815235

[2] https://github.com/Metacello/metacello/issues/474

[3] https://github.com/Metacello/metacello/issues/475


On 12/19/17 10:25 AM, Vitor Medina Cruz wrote:
> Hello,
>
> Using github://<github_path>/<srcpath> metacello works fine, but is
> there another more general way of refering to a remote git repo? From
> BitBucket or Gitlab for example.
>
> Regards,
> Vitor

CyrilFerlicot wrote
> For bitbucket you can use bitbucket://.
> I don't know for gitlab.

Unless something has changed, the cool git URLs only work for public
projects. In any case, it was not possible to authenticate with SSH keys
last time I checked (so I could not use them)…



-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sean,

I am under the impression that iceberg is able to authenticate with SSH
keys .... I am not a pharo/iceberg user myself, but it seems that
iceberg should be able to fill that gap.

Dale


On 12/19/17 7:02 PM, Sean P. DeNigris wrote:

Au contraire! It works really good with SSH keys. I work all day with it. I added support for bitbucket to iceberg because I’m using bitbucket private repos in my company.

Norbert

Hi,

We also use private GitHub projects with Iceberg and it works fine.

Cheers,
Doru


--
www.tudorgirba.com
www.feenk.com

"We cannot reach the flow of things unless we let go."

On Tue, Dec 19, 2017 at 07:07:16PM -0800, Dale Henrichs wrote:
> I am under the impression that iceberg is able to authenticate with
> SSH keys .... I am not a pharo/iceberg user myself, but it seems
> that iceberg should be able to fill that gap.

Iceberg does, with RSA keys. Iceberg didn't work for me with ED25519 keys.

Pierce

These days, we are getting to the point where I am beginning to flip the question on it's head and begin thinking that it should be possible for  a developer to choose to have have the github:// url interpreted as "create a local clone of the remote repository" instead of "download a tarball of the remote repository" . With this approach it should be possible to include gitlab url support as well since the gitlab issue is related to the specific handling of repository tarballs..

Using  'git clone --depth=1'  don't do the trick and leave the process both efficient and general accross all git repos?

At the time that github:// was added (5 years ago now?) git could not be counted upon to be installed by the folks who may be interested in depending upon a project hosted on github, so the tarball approach was used so that those brave souls interested in using git and github could do so without forcing everyone else  to start using git ... nowadays with git becoming part of the mainstream dev env for Smalltalk, git (or libgit2 in the case of pharo) can be counted on to be available ...

On Tue, Dec 19, 2017 at 4:49 PM, Dale Henrichs <[hidden email]> wrote:

BitBucket is supported with like Github with: butbucket://<butbucket_path>/<srcpath>.

With regards to GitLab, their download zip format is/was different enough from BitBucket/Github to make it difficult to provide the same level of support. See the series of comments here[1].

When the github:// was first introduced it was done in such a way that users of projects on GitHub did not have to have git installed on their local computers ... it was a way to make it possible for folks to begin using git without requiring everyone to install git ...

These days, we are getting to the point where I am beginning to flip the question on it's head and begin thinking that it should be possible for  a developer to choose to have have the github:// url interpreted as "create a local clone of the remote repository" instead of "download a tarball of the remote repository" . With this approach it should be possible to include gitlab url support as well since the gitlab issue is related to the specific handling of repository tarballs...

... there are current discussions in this area on these two issues [2] and [3].

Dale

[1] https://github.com/Metacello/metacello/issues/287#issuecomment-59815235

[2] https://github.com/Metacello/metacello/issues/474

[3] https://github.com/Metacello/metacello/issues/475

On 12/19/17 10:25 AM, Vitor Medina Cruz wrote:

Hello,

Using github://<github_path>/<srcpath> metacello works fine, but is there another more general way of refering to a remote git repo? From BitBucket or Gitlab for example.

Regards,
Vitor

Hi Pierce,

Le 20/12/2017 à 17:17, Pierce Ng a écrit :
> On Tue, Dec 19, 2017 at 07:07:16PM -0800, Dale Henrichs wrote:
>> I am under the impression that iceberg is able to authenticate with
>> SSH keys .... I am not a pharo/iceberg user myself, but it seems
>> that iceberg should be able to fill that gap.
>
> Iceberg does, with RSA keys. Iceberg didn't work for me with ED25519 keys.

does command line git work with those ED25519 keys?

Regards,

Thierry

>
> Pierce
>
>
>

Tudor Girba-2 wrote
> We also use private GitHub projects with Iceberg and it works fine.
>> Au contraire! It works really good with SSH keys. I work all day with it.
>> I added support for bitbucket to iceberg because I’m using bitbucket
>> private repos in my company.

This is very intriguing. So you're saying one can now use GH and BB URLs to
access private repos in baselines for dependent projects and they will be
loaded via SSH keys?



-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Yes, I have projects that are loaded from bitbucket private repos and that have dependencies to public github and private bitbucket repos all at once. Not a problem on my dev machine. On jenkins it is more of a problem. There the ssh keys are provided by the jenkins server but if a dependent project is also private there needs to be ssh keys in the environment. Second thing is that the linux 64bit vm is pretty unstable. This could be avoided using filetree and zip downloads from git but there is no way providing credentials to the https download. Either way not good. I even made one project public in order to load it

Norbert
>
>
> -----
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

NorbertHartl wrote
> I have projects that are loaded from bitbucket private repos and that have
> dependencies to… private bitbucket repos all at once.

Is `Iceberg enableMetacelloIntegration: true` what gets around the tarball /
SSH-support issue?



-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

> Am 21.12.2017 um 15:54 schrieb Sean P. DeNigris <[hidden email]>:
>
> NorbertHartl wrote
>> I have projects that are loaded from bitbucket private repos and that have
>> dependencies to… private bitbucket repos all at once.
>
> Is `Iceberg enableMetacelloIntegration: true` what gets around the tarball /
> SSH-support issue?

Yes, metacello git integration will not download tarballs but checkout the git repo and therefor ssh can be used.

Norbert

On Wed, Dec 20, 2017 at 06:08:16PM +0100, Thierry Goubier wrote:
> >Iceberg does, with RSA keys. Iceberg didn't work for me with ED25519 keys.
> does command line git work with those ED25519 keys?

Yes. I have been using GH with ED25519 keys.

I added RSA keys to my GH setup specifically for Iceberg. I looked and found
out that libssh2 or libgit2 (forgot which) used by Iceberg does not support
ED25519 keys.

Pierce

Vitor Medina Cruz wrote
>> I don't know for gitlab.

It doesn't seem to work (in Pharo 6.1). `LGit_GIT_EEOF`. I see there is
MCBitbucketRepository but no MCGitlabRepository.



-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

> On 2 Jan 2018, at 16:43, Sean P. DeNigris <[hidden email]> wrote:
>
> Vitor Medina Cruz wrote
>>> I don't know for gitlab.
>
> It doesn't seem to work (in Pharo 6.1). `LGit_GIT_EEOF`. I see there is
> MCBitbucketRepository but no MCGitlabRepository.

MC*Repository is not iceberg but monticello api.
Iceberg supports gitlab projects (both public and private servers) and I know there is people using them.
If you are getting LGit_GIT_EEOF is likely a bug or a problem when declaring repo… but the information you are giving is not enough to know :)

Esteban

>
>
>
> -----
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>

EstebanLM wrote
> MC*Repository is not iceberg but monticello api.

Except it is extended by Iceberg-Adapters for #httpsUrl and #scpUrl! Also,
MCBitbucketRepository is hardcoded in
IceProviderRepositoryType>>#mcRepository, which was mangling the URL (off
the top of my head I assume because 'bitbucket' is longer than 'gitlab').
This is all in #60528. I don't see how people could be using this unless
it's fixed in 7.0 (which it doesn't appear to be because there still seems
not to be an MCGitlabRepository) or they are using filetree:// or similar
URLs in their baselines.



-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html