[Cuis-dev] Package dependencies satisfaction (was Re: Converting Tonel packages)

Fri Aug 30 07:19:00 PDT 2019

Hi Juan,

Le ven. 30 août 2019 à 15:38, Juan Vuletich <juan at jvuletich.org> a écrit :
>
> Hi Thierry,
>
> On 8/30/2019 8:39 AM, Thierry Goubier via Cuis-dev wrote:
> > Hi Chris, David,
> >
> > thanks guys.
> >
> > Out of topic, but related. Do package dependencies satisfaction a
> > significant issue in development and deployment, and if yes, how that
> > could be addressed?
> >
> > I'm familiar with Metacello/Gofer up to the version ordering
> > implementation details and the constraints it brings on the filetree
> > implementation; I'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).

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)

> 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.

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

> Thanks,
>
> --
> Juan Vuletich
> www.cuis-smalltalk.org
> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
> https://github.com/jvuletich
> https://www.linkedin.com/in/juan-vuletich-75611b3
> @JuanVuletich
>
>
> > Le ven. 30 août 2019 à 07:06, Chris Muller via Cuis-dev
> > <cuis-dev at lists.cuis.st>  a écrit :
> >> On Thu, Aug 29, 2019 at 5:41 PM David T. Lewis via Cuis-dev<cuis-dev at lists.cuis.st>  wrote:
> >>> Thierry,
> >>>
> >>> I am a casual user of various git tools in Cuis, Squeak and Pharo,
> >>> and your explanation is very helpful for me to understand some of
> >>> the tradeoffs.
> >>
> >> +1 me too.    :)
> >>
> >>
> >>>
> >>> Thanks,
> >>> Dave
> >>>
> >>>
> >>> On Thu, Aug 29, 2019 at 12:52:56PM +0200, Thierry Goubier via Cuis-dev wrote:
> >>>> Hi Philip,
> >>>>
> >>>> as someone who has worked a bit on filetree, I'd say there are no
> >>>> philosophical differences. Just implementation compromises with the way
> >>>> Smalltalk has to deal with the world outside of the image for storing code.
> >>>>
> >>>> For example, Tonel has been introduced to solve issues with filetree: the
> >>>> fact filetree generates too many files creating performance issues with the
> >>>> host filesystem implementation (and issues with the poor support of Windows
> >>>> long paths in the virtual machines), and losing space because the files are
> >>>> small (and that current storage tech has solved its performance issues with
> >>>> large files by forcing a large minimum allocation size). Filetree is itself
> >>>> a compromise to have a different fit with current version management
> >>>> systems (git, for example). As I said, just implementation compromises(*),
> >>>> no philosophy behind that.
> >>>>
> >>>> If there is a philosophical difference, I would say that there is only one:
> >>>> declarative or imperative storage format. Traditiional Smalltalk is
> >>>> imperative... you don't load code, you execute a program. Newer formats
> >>>> like filetree or tonel, or probably the database-oriented ones (VW, Magma)
> >>>> are more declarative in nature (but have still imperative parts).
> >>>>
> >>>> The picture grows more complex if you consider what are version control
> >>>> systems. They are in fact databases (even git), so a more natural fit for
> >>>> Smalltalk would be an object persistency layer used with code objects (VW,
> >>>> again. Gemstone?).
> >>>>
> >>>> To give you an idea of how that looks, for all formats:
> >>>>
> >>>> In Smalltalk, you have code as an object graph (class, CompiledMethod
> >>>> instances, etc...) with an optimisation to store the text (the sources and
> >>>> changes files). When you save, you iterate over that object graph and
> >>>> convert it to a file / multiple files. Then you interact with your version
> >>>> control system to record the files (either automatically or manually). Then
> >>>> your version control system store your changes into a database, as a set of
> >>>> objects...
> >>>>
> >>>> This also explains why you have those Smalltalk to database for storing
> >>>> code implementations: avoid that file layer that is extremely annoying.
> >>>>
> >>>> Thierry
> >>>>
> >>>> (*) For example, the last version of GitFileTree, a git-enabled filetree,
> >>>> never manipulates any files in Smalltalk. Git does file operations but only
> >>>> as a kind of user interface layer, to allow users to solve conflicts.
> >>>>
> >>>> Le jeu. 29 ao??t 2019 ?? 10:26, Philip Bernhart via Cuis-dev<
> >>>> cuis-dev at lists.cuis.st>  a ??crit :
> >>>>
> >>>>> Hi Hernan,
> >>>>>
> >>>>> could you find out the philosophical differences regarding
> >>>>> the "new" package formats like filetree or tonel?
> >>>>>
> >>>>> If yes, what are they? I'm curious why thinks are supposed to
> >>>>> be better the way pharo and visual works (?) went.
> >>>>>
> >>>>>
> >>>>> Thanks for your time,
> >>>>> Philip
> >>>>>
> >>>>> Hernan Wilkinson via Cuis-dev<cuis-dev at lists.cuis.st>  writes:
> >>>>>
> >>>>>> well well well, even I do admire you and so on, I would not call it a
> >>>>>> date ????????
> >>>>>> (we are starting to have fun!!)
> >>>>>>
> >>>>>> On Wed, Jul 31, 2019 at 4:44 PM Dale Henrichs via Cuis-dev<
> >>>>>> cuis-dev at lists.cuis.st>  wrote:
> >>>>>>
> >>>>>>> Hernan,
> >>>>>>>
> >>>>>>> Excellent! It's a date then:)
> >>>>>>>
> >>>>>>> Dale
> >>>>>>> On 7/31/19 12:32 PM, Hernan Wilkinson via Cuis-dev wrote:
> >>>>> --
> >>>>> Cuis-dev mailing list
> >>>>> Cuis-dev at lists.cuis.st
> >>>>> https://lists.cuis.st/mailman/listinfo/cuis-dev
> >>>>>
> >>>> --
> >>>> Cuis-dev mailing list
> >>>> Cuis-dev at lists.cuis.st
> >>>> https://lists.cuis.st/mailman/listinfo/cuis-dev
> >>> --
> >>> Cuis-dev mailing list
> >>> Cuis-dev at lists.cuis.st
> >>> https://lists.cuis.st/mailman/listinfo/cuis-dev
> >> --
> >> Cuis-dev mailing list
> >> Cuis-dev at lists.cuis.st
> >> https://lists.cuis.st/mailman/listinfo/cuis-dev
>