metacello
metacello copied to clipboard
Metacello
Questions: How to manage private projects on private server?
Hi,
I have a gitlab installed on my private server. Also, this server use a custome SSH port. Via command line, I manage the project with this remote: ssh://[email protected]:3456/Projet/Bazard.git
My questions are:
- How can I use Metacello to load this project? How should I manage the fact it is private an requires identification? (And also different ssh port)
- How can another project depend on this one? What should I use for the spec?
It could be cool if this was covered by the documentation.
Thank you in advance.
Hi @jecisc ,
I've designed GitFileTree integration with Metacello to be able to do things like that, but haven't added the support for ssh urls and ports. But that could be added easily, but only if you either accept to write the authentification by hand in the url, or use ssh keys.
In short, Metacello can be extended to do that, with the aid of the use of the lock command eventually.
Hi,
I accept to have authentication in the URL or use ssh key but it would be good to have both. Sometime it's not worth to lose time to set up the SSH, but we need ssh when we don't want a clear password in the URL.
It would be great if Metacello could be extended. I use tonel for my repository so I guess it will not work with GFT. (Also I would like to not load GFT because I try to build all my images in Jenkins which is on a linux server while I am working on a windows. The version of GFT will not be the good one).
Well, a gitfiletree url accept both: in the URL (for https) and with ssh keys (for the old style ssh git urls).
Metacello could be extended; this is what gitfiletree does. Now, tonel has been integrated into Metacello, and Iceberg handles urls for tonel (and for Metacello), so this feature should be handled by Iceberg (which is then limited to what libcgit supports).
The only thing one could like, is an easier way for Metacello to handle extensions. And write those extensions, of course, because what you ask, gitfiletree would support it (as long as the pharo vm is not hitting the too long file paths bugs linked with filetree). For Tonel, you would need to ask the relevant features to be added to Iceberg, and use Iceberg's Metacello integration.
The use of private git repositories was the first (and utmost) need for gitfiletree (because I really, really need it to do my job).
@ThierryGoubier and @seandenigris do you guys have a proposal for a better way to handle extensions for custom urls?
I think my preference would be something along the lines of a custom url handling class that whose job is to create a repository that conforms to the basic MCRepository/FileTree/Tonel api ... and then the code in MetacelloGemStonePlatform>>createRepository: would be changed to something like the following:
"...check for known repository types ... then if no matches found ('http' type) defer to custom URL implementation to create the correct repository"
^ aRepositorySpec description asUrl createRepository
However, I don't think this is possible. On Pharo, as I understand it, all urls end up being an instance of ZnUrl ... prior to ZNUrl it was possible to create a custom scheme class that would have made it possible to do the above ... So my question is basically "what is the accepted practice for creating and dealing with custom urls on Pharo?" ... then depending upon what it is possible to do in Pharo, we'll come up with a solution for Metacello ...
@dalehenrich ; yes, I talked with Sven about a way to extend ZnUrl for that purpose, when I was sort of fighting with gitfiletree:// urls, without success.
I think one could still do it in Metacello, but Metacello would have the structure for handling the delegation and we would extend it by creating subclasses:
^ aRepositorySpec description asUrl
in: [ :aZnUrl |
(MCUrlHandler allSubclasses
detect: [ :e | e handle: aZnUrl scheme ]) repositoryFromUrl: aZnUrl ]
That would be my suggestion.
I know that Iceberg can manage urls like this for remote: ssh://git@url:port/team/project.git but looking at the code I see that the parse of the url is done via a regex:
parseUrl
| matcher |
matcher := '(ssh\://)?([\w\-]+@)?([\w\-.]+)(\:[\d]+)?(\:|/)/?([\w\-]+)/([\w\-]+)(\.git)?' asRegex.
(matcher matches: url)
ifTrue: [
host := matcher subexpression: 4.
owner := matcher subexpression: 7.
projectName := matcher subexpression: 8.
]
ifFalse: [ IceWrongUrl signal: 'Could not parse URL: ', url ]
If ZnUrl is extended to manged this kind of url, iceberg can maybe profit from that too.
Maybe @estebanlm can be interested by this discussion.
@jecisc : interesting... I would have reused ZnUrl to do that, but maybe they wanted to avoid ZnUrl errors about unknown schemes. I had to copy/paste some of the ZnUrl code into GitFileTree for that purpose.
If Metacello or another project use a regex like this one it would be good if every project related to git management use the same thing because I saw multiple PR on Iceberg to improve this regex.
@jecisc : if Metacello and GitFileTree reuse ZnUrl, they don't have a need for that regex.
Also, the scheme I suggested above would allow Iceberg to keep using its regex (by reprinting the ZnUrl as a string... even if it is a bit silly).
Like I said earlier, the old Url hierarchy did not have issues with allowing for custom parsers or havine to require to regex schemes (yikes) or workaround apparent limitations in the ZNUrl implemenation ... Are you telling me that in order to do something that used to be very simple is going to take major hackery to work with Pharo??? This seems to be a sad state of affairs ....
--- yes I've got a satisfactory scheme implemented in GemStone using the old Url hierarchy ---
Well I still don't quite understand what it takes to get the whole thing working satisfactorily for Pharo, but I would prefer to see a pull request with the proposed pharo implementation, so we can figure out how to create a solution that works consistently for Pharo/GemStone/Squeak ... GemStone has ZNUrl, but because of it's "limitations" I've kept the Url hiearchy as well, so that I don't have to resort to ugly shenagins ...
I don't have a lot of knowledge on this area so I cannot help a lot.
I tried to execute this:
'ssh://[email protected]:3456/Projet/Bazard.git' asZnUrl
And I get an instance of ZnUrl of the ssh scheme, gitlab.ferlicot.fr as host, 3456 as port, git as username and #('Project' 'Bazard.git') as segments.
Just for info. #asUrl returns exactly the same.
'ssh://[email protected]:3456/Projet/Bazard.git' asUrl = 'ssh://[email protected]:3456/Projet/Bazard.git' asZnUrl "true"
Cool ... is it legal to add an extension method to ZNUrl (like createMetacelloRepository) so Squak and GemStone can leverage the Url hierarchy to parse the urls as well as implement the expexpected behavior?
My guess is that MCUrlHandler is an attempt to restore some of the old Url hierarchy behavior and I don't want to require that ZNUrl and MCUrlHandler be used on platforms where better alternatives exist ...
Cool! If we can get to the point where:
"...check for known repository types ... then if no matches found ('http' type) defer to custom URL implementation to create the correct repository"
^ aRepositorySpec description asUrl createRepository
does the job, then it is only necessary to publish a standard set of urls that are expected to work cross-platform, write some tests and "Bob's your uncle."
He said that Metacello is already dependant on Zinc (I see it on MetacelloPharoPlatform at least). So there is no problem dependencies wise to extend ZnUrl.
Cool! then I would like a sanity check for why the iceberg folks felt it necessary to go with a regex expression and why @ThierryGoubier is worried about "ZnUrl errors about unknown schemes" ... perhaps things are not as simple as they seem?
Is there a list of the "Metacello repository urls" that are in current use ... I know there are several but I have not seen a canonical list anywhere ... my "new" urls are not public yet, so I will be able to adapt them to existing schemes as appropriate ...
Along these lines I think it would be a good idea to introduce the notion (if it hasn't already been introduced) of allowing a developer to choose to have a github:// or bitbucket:// url turned into a local git clone instead of downloading the tarball ... this would allow us to standardize on a fairly small set of common url patterns that can be directed at particular tools at the developers whim, rather than requiring that each platform come up with a custom set of urls for every new tool that pops up ... What do you guys think (@estebanlm are you following this thread?)
@dalehenrich
Iceberg has an option "enableMetacelloIntegration".
When it is activated and we load a project via Metacello, it will clone the project and all its git dependencies.
For esteban, I think he is in Holidays. Maybe he will not be able to answer soon.
(Also, since Pharo 6, Pharo comes with libgit2 vm plugin, so no need to have git installed)
Does iceberg handle all of the ssh agents and such when dealing with private repositories?
For now Iceberg handle SSH agent on linux and OSX. (There is problem with windows)
Else, there is a setting to reference the ssh key directly.
In case you haven't seen it, a related discussion has popped up on the Metacello Google group ... @jecisc, I approved your membership ... I own the group using a different google id than the one that I use for work and while in the past I've set up forwarding of email from that account to my "current account" google seems to periodically stop forwarding without sending any notification to the forwardee, so I go years before realizing that I'm not longer getting email --- no activity on that account EXCEPT notification of new Metacello group members:) ... sorry about that ...
@dalehenrich No problem. When discussions are scattered everywhere, it is hard to follow everything. I can't blame when I know it can happen to me!
I'll read the discussions.
@dalehenrich
Bad news. See this thread: http://forum.world.st/Iceberg-regex-td5061690.html
If I do
'[email protected]:Projet/Bazard.git' asZnUrl
And I get an instance of ZnUrl #('[email protected]:Projet' 'Bazard.git') as segments.
I was suspicious that ZNUrl was not going to provide support for parsing arbitrary urls ... @ThierryGoubier apparently has worked around the issue, but I don't know the exact details ... Like I said the old Url hierarchy was very flexible and useful and it is unfortunate that Pharo is stuck with something not quite as flexible ....
Yes, it would be nice to be able to manage non-standard urls ... I'm wondering if @ThierryGoubier has already talked to Sven and presumably the iceberg guys are using regex because they can't use ZNUrl ... so I'm not going to hold my breath:)
Sorry for not having read the entire thread. Could #534/#536 be helpful in this context? :-)
