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

Tue Sep 3 17:54:08 PDT 2019

I might have been the first person to suggest Git for Cuis. My goal was to make it easy for people coming in from other systems to adapt to Smalltalk. 

Juan and I had a longish back and forth. He did the work needed to support Git. I have never been completely satisfied with .pck as a solution myself, but it does seem to have served the community well enough while also integrating cleanly with the most popular SCM on Earth, and that’s really what matters.

This isn’t to say: this is the only solution. 

We should at least try to listen to folks who have different ideas about how we ought to keep our source code. They may be onto an idea we haven’t had. 

There is a fundamental dichotomy between a living system that can’t be reconstituted from first principles (which is what everything else does when you start it up) and what we have here. We have to both deal with being “the weird kid” and also live in the modern world. 

Everyone has an opinion. Let’s focus on the balance of facts, *as well as* our own gut instincts. This has always been a forum where disparate points of view are accepted; Juan’s first email to me was accusatory, said I was spreading F.U.D. Really, I was just uncertain. And yet we became fast friends. 

If you have different ideas about source code and revision management, we should kindly, as a culture, hear what you have to say. Whether or not we agree with you as a group or are convinced that we should change our habits. Your voice is still worth hearing. 

In spite of having been the guy who said “we need to make it work with Git” I do want to hear about other strategies, and I’m afraid that I cannot make it to ESUG.

Please share? *nudge*

—C

> On Aug 30, 2019, at 6:38 AM, Juan Vuletich via Cuis-dev <cuis-dev at lists.cuis.st> wrote:
> 
> 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).
> 
> 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
> 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
> 
> -- 
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev