, ma.chris.m@gmail.com
Hi
[snip]
Is package dependencies satisfaction a significant issue in development and deployment, and if yes, how could that be addressed?
I am familiar with Metacello/Gofer up to the version ordering implementation details and the constraints it brings on the filetree implementation;
I have ve seen recently in the golang space this (https://blog.golang.org/versioning-proposal) and all the Russ Cox blog posts on the subject. How does Cuis stands about that?
Regards,
Thierry
Cuis packages specify their requirements. To avoid hardcoding other package names, a package can declare that it provides some functionality, For example,
VectorGraphics.pck.st
includes these lines near the start of the file:
!provides: 'VectorGraphics' 1 81!
!requires: 'Color-Extras' 1 nil nil!
!requires: 'Collections-CompactArrays' 1 2 nil!
So, before loading this package, Cuis tries to find some packages that provide 'Color-Extras' with version 1.x of the functionality, and 'Collections-CompactArrays' with version 1.x, but at least 1.2. This package provides 'VectorGraphics' functionality with version 1.81, for anyone that could need it (For example loading TrueType fonts).
There's no provision for declaring where to find a package file that fullfills a requirement.This is done on purpose, to avoid any dependency on github or such.
But if you clone https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev and run Cuis there, Cuis can automatically find all the included packages. For example, you can evaluate
Feature require: 'BaseImageTests'
And open SUnit to run all the tests written for the base image. Or you can evaluate
Feature require: 'CorePackages'
to load all the packages included in the main Cuis repo, with all their tests.
Additionally if you run the included clonePackageRepos.sh script, Cuis will be able to find all the packages included in all repos of the https://github.com/Cuis-Smalltalk GitHub organization. This includes most code written for Cuis.
For repos outside the Cuis organization, you need to clone them by hand, in a folder where Cuis can find them.
See https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Documentation/CuisAndGitHub.md and https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Documentation/AdditionalPackagesForCuis.md
This approach lets us take advantage of most of the functionality provided by Git and GitHub (familiarity with the git commandline required), without tying the image to them, and without requiring additional code in the base image. It has worked well so far.
Thanks,
Juan Vuletich
To: Juan Vuletich
Cc: Thierry Goubier , Discussion of Cuis Smalltalk , ma.chris.m@gmail.com
Hi Juan,
Understood.
Is there a provision for handling competing, and eventually
conflicting requirements? For example, two packages provides A, but
one requires B version 1.x whereas my package requires A and B version
2.x. Or did you choose in the requires, to disallow that sort of
constraint (i.e. anything requiring B v1.x will be satisfied by B
v2.3)
Yes, that is a sound principle.
If I understand well how this is done, then: Cuis implements a
dependencies satisfaction algorithm, a format for expressing provides
and requires, and a filesystem convention to scan for packages,
independent of the code versioning system used?
Thanks,
Thierry
