[Cuis] Supporting packages with their own Git repository was: Loading StyledText using a script

Juan Vuletich juan at jvuletich.org
Sun Jul 28 14:52:50 CDT 2013


Hi Folks,

On 7/28/2013 2:01 PM, Bernhard Pieber wrote:
> Hi all,
>
> I really like the new Feature feature. I understand that it is not yet fully fleshed out. I would like to contribute a little.
>
> First some assumptions:
> 1. Not every package should live in the Cuis-Smalltalk repository.
> 2. You cannot easily have one repository inside another repository. (I did some research on that.)
> 3. You don't want to put required all packages in every repository that needs them.
> 4. The Feature feature should still work.
> 5. You don't want to copy the packages directory out of the repository directory into your image directory. (If you did you would need to copy packages back every time you saved them and wanted to commit. Too clumsy, IMHO.)
> 6. The image directory itself should not be a repository. (Too many files you would need to ignore.)
>
> Suppose I have two packages PackageA and PackageB living in their own repositories. If we can agree on the assumptions this leads to a directory layout similar to this one:
>
> MyProject
> 	MyProject.image
> 	MyProject.changes
> 	Cog.app
> 	CuisV4.sources
> 	Cuis-Smalltalk
> 		.git
> 		README.md
> 		Cuis4.2-1766.image
> 		Cuis4.2-1766.changes
> 		Packages
> 			Compression.pck.st
> 			Sound.pck.st
> 			...
> 	Cuis-Smalltalk-PackageA
> 		.git
> 		README.md
> 		PackageA.pck.st
> 	Cuis-Smalltalk-PackageB
> 		.git
> 		README.md
> 		PackageB.pck.st
>
> I would like to be able to specify that PackageA requires PackageB and load both of them using the following:
> (Feature name: #PackageA) require
>
> I guess this would not work currently because the code would not search the directory Cuis-Smalltalk-PackageB.
>
> How to solve this? I discussed a bit with Juan and we came up with some possible solutions:
>
> a) Search all subdirectories of the image directory whose name starts with "Cuis-Smalltalk" (and possibly subdirectories named Packages?)
> It would rely on the convention that everyone names their Cuis package repositories accordingly. IMO this would be good anyway for consistency and SEO reasons.
>
> b) Tell Feature which paths to search, e.g. Feature addPath: './Cuis-Smalltalk-PackageA'; addPath: './Cuis-Smalltalk-PackageB'; ...
> Then everyone could put their repositories where they want and name them like they want. The big problem I see with this is that you would have to execute this script for every image you create.
>
> Having written this e-mail, I definitely prefer a) because:
> 1. It is easier to use. You just clone the Cuis-Smalltalk and any package repository you need into your image directory. The Feature feature just works.
> 2. You don't need to mess with paths in the image. (They look differently on Windows, Mac, and Linux.)
> 2. It satisfies "Convention over configuration".
> 3. It is easy to create a UI to list all possibly installable features.
> 4. We probably would not need the path inst var in Feature, right? This would make it much easier to release images with packages loaded.
> 5. If we would
>
> What do you all think?
>
> Cheers,
> Bernhard
>
> Anfang der weitergeleiteten E-Mail:
>
>> Von: Bernhard Pieber<bernhard at pieber.com>
>> Betreff: Loading StyledText using a script
>> Datum: 27. Juli 2013 19:10:43 MESZ
>> An: Discussion of Cuis Smalltalk<cuis at jvuletich.org>
>>
>> Hi Juan,
>>
>> I succeeded in loading the StyledTextEditor using a FileList. Installation is much easier in Cuis 4.2 thanks to the new Feature feature. Great!
>>
>> I would like to build a script to load all packages. However, it seems that currently loading packages in subdirectories of the packages folder, e.g. the StyledTextEditor, currently does not work. Should the following work?
>> (Feature name: #StyledText) require
>>
>> I believe it would be better if the development image had all packages loaded to make sure everyone develops with all supported packages loaded. I guess this is a problem with the path inst var in Feature, right?
>>
>> Cheers,
>> Bernhard
>

I like option a).

The pathname ivar in Feature should go away. I guess that the similar 
ivar in CodePackage should be cleared at image save, to avoid problems 
when moving to another machine... Or maybe use the same logic to detect 
that the image was likely moved to another machine that is being used to 
clear user initials. I need to take a look at this.

I'll be working on this while I integrate later changes to Features by 
Ken, to support reqs with valid version ranges, and a few other 
enhancements.

Please keep posting any further suggestions and comments...

Cheers,
Juan Vuletich




More information about the Cuis mailing list