[Glass] Failing to add a valid project entry in GsDevKit_home

[Dale Henrichs via Glass]

On 12/22/17 5:10 AM, Mariano Martinez Peck wrote:
> Hi Dale,
>
> What I am trying to do is.... right now the configuration of my 
> application does reference git based projects via github url. This was 
> OK (even if not ideal) until I reached ZipArchive error of the other 
> day. So... I am trying to migrate to an approach like this:
>
> 1) Clone repositories to local machine (I am trying to do this via 
> Iceberg in dev and via GsDevKit_home / tODE on production)
> 2) Do a metacello load pointing to the local filestree and then lock
Okay so the project isn't loaded yet ... I guess that is true because of 
the ZipArchive problem ...
>
> With that in mind, for the GemStone side what I am trying is:
>
> a) Put .ston files for each of the projects  I refer that are in Git 
> (Seaside, HighcartsSt, etc) in to `/sys/local/server/projects` *(is 
> this the recommended place????)*.
Certainly ... the rule would be that if you have projects that are to be 
shared amongst a collection of stones, then use 
`/sys/local/server/projects` ... the only time to use the 
`/sys/stone/projects` is when you want to do work on a branch that is 
explicitly not shared ... I use this approach when I doing work on 
Metacello that is likely to break Metacello while I am working on it -- 
I cannot afford to break Metacello for all of the other stones:)
> That way, each new server will get all needed .ston as they are 
> sincronized together with my sys local project.
> b) do a `project install` ,  `project load` and `project lock` of 
> those projects.
exactly...
>
> Does this make sense?
Yes it does!
>
> Well, I thought it had. But... I just tried `project clone` and it 
> seems it ALSO downloads a the zip tarball using ZipArchive. Damn it. I 
> thought you were were using git (via FFI, or performOnServer or 
> whatever) underneath for making the clone...
Yes, I think this bit is a bit inadvertant, but without the ZipArchive 
bug is certainly an annoyance at most ... with the bug this is a problem 
--- but it should be easy to work around this ...simply define the 
project entry to use the github:// and the master branch (which 
downloads correctly) and do your `project clone` - no lock in project 
entry... another alternative is to manually clone the repo into 
$GS_HOME/shared/repos and thenn define the project entry referencing the 
filetree:// url for the repo - use a lock now ... and then you're ready 
to rumba ...
>
> So what are the alternatives?  if I remove the `--https` and I change 
> the url to be the git / ssh keys , would that avoid doing a zipball 
> download?  I ask before starting to deal with the keys etc..
The simplest is to clone the repository manually and then create the 
project entry and just avoid the whole ZipArchive bug completely ... The 
ony reason that all of the examples use github:// urls is a) I didn't 
really realize that the project entry would automactically do the 
download and b) I didn't know about the ZipArchive bug that could get in 
the way ...
> If not, then the only way I find is to make the clone myself, using 
> git. But then, the project entry makes almost no sense, I cannot use 
> `project clone` etc etc.
The project entry is used as a specification for other stones that are 
created in the $GS_HOME env ... so you don't have to "teach" each knew 
stone where all of the local clones for projects are located ...

I am patiently waiting to see if the pharo folks see the advantage of 
having these disk-based artifacts, but I may have to retire before that 
happens:) ...

For 3.5 we should have Cypress2 (called Rowan now) and Metacello in the 
base along with selected bits of tODE tools api as we have a few of our 
commercial customers who are becoming interested in using git for 
managing the GemStone source ... so it is likely that I will revisit the 
project entry implementation and probably come up with a Metacello Load 
Specification which will be similar to project entries, with some tweaks 
and changes based on my/our experiences so far ...

For 3.5 I plan to move towards using GsDevKit/GsDevKit[1], 
SeasideSt/Grease[2] and Metacello/metacello[3] instead of glassdb/glass, 
GsDevKit/Grease and dalehenrich/metacello-work ... and that is going to 
push the limits of what can be done with the single 
$GS_HOME/shared/repos and $GS_HOME/sys/local/server/projects directory 
structure. The methods and classes themselves have not changed (that 
much)between projects,  but the fact that they are independent git 
projects (some with the same name) and the fact that I don't want to 
force any existing stones to have to switch projects makes it a bit of a 
challenge ...

So things are constantly being refined as  time goes by and the 
requirements/experiences change.

Dale

[1] https://github.com/GsDevKit/GsDevKit
[2] https://github.com/SeasideSt/Grease
[3] https://github.com/Metacello/metacello
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20171222/3f8c1eba/attachment.html>