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

Juan Vuletich juan at jvuletich.org
Fri Aug 30 08:57:36 PDT 2019 

On 8/30/2019 11:19 AM, Thierry Goubier wrote:
> 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)

Most packages don't specify version requirements, but if we had already 
loaded some package:
provides: 'A' 1 23 (feature A, version 1.23)

Some examples. Someone doing
requires: 'A' nil nil nil (feature A, any 
version)                                ->   OK
requires: 'A' 1 nil nil (feature A, version 1.0 or later)                
      ->   OK
requires: 'A' 1 7 nil (feature A, version 1.7 or later)               
         ->   OK
requires: 'A' nil nil 2 (feature A, version 0.x, 1.x or 
2.x)                ->   OK
requires: 'A' 2 nil 2 (feature A, version 2.x strictly)            
             ->   OK
requires: 'A' 3 nil 5 (feature A, version 3.x, 4.x or 
5.x)                  ->   Not OK (*)

In the last case, (*) load will fail.

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

Yes. Exactly.

> Thanks,
>
> Thierry

Cheers,

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



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

More information about the Cuis-dev mailing list