[Cuis-dev] Package Installer & Package Downloader

[Mariano Montone]

Another thing to consider:

In Common Lisp world, there's Quicklisp as package downloader. To build 
the package list, the package is downloaded and loaded. If the load 
fails, then the package is not included in the package list; package 
makes it to the package list only if load succeeds.

I imagine something similar could be implemented to build the list of 
packages for Cuis.

That would not have solved the problem for your package, as the problem 
is only observable as you try to run. But at least it would discard the 
packages that don't load at all; that's a good thing.

It would make the building of the list more difficult, but could be 
worth considering nonetheless.

I'll take a look at that too ..

El 29/5/22 a las 18:19, Mariano Montone escribió:
> Hi Ken,
>
> I agree with you it would be good that PackageDownloader were better.
>
> Some of its faults IMO are:
>
> 1. its disregard for package versions in its current implementation.
> 2. sync with current available packages.
> 3. the package downloader package list can get out of date, because I 
> update it manually.
>
> I don't see an easy solution for 2). Apart from traversing disk, which 
> can be quite time consuming, depending on user setup. (it is for me, 
> for example).
> And for 1), well, it should at least start looking at versions of 
> packages and act accordingly; something I haven't done yet..
> About 3), it is not ideal, but perhaps we can live with that; unless a 
> CI system is introduced.
>
> About your idea of marking packages as "released", I think we could 
> extend the PackageDownloader to parse CodePackage 'description' 
> instance variables, and extract #tags from there. Then add a tags 
> filter in PackageDownloder tool; doesn't sound hard.
>
> How does that sound?
>
> Cheers,
>
> Mariano
>
> El 29/5/22 a las 15:07, ken.dickey at whidbey.com escribió:
>> It is very nice to have the Package Downloader look for and find Cuis 
>> packages.
>>
>> One wants this to be a bit more robust.  I would like to see only 
>> packages which could be successfully loaded.
>>
>> There are cases where this is less than helpful.
>> [A] Packages under development or otherwise incomplete
>> [B] Packages which require/depend upon other packages or code 
>> available if a repository is cloned, but are unavailable if not.
>>
>> It would seem to me that if we added some "released" marker to 
>> packages which are expected to be loadable stand-alone and only show 
>> those, there would be less confusion in our world.
>>
>> Perhaps #ReleasedStandAlone marker simular to the Provides/Requires 
>> markers?
>>
>> Thoughts?
>> -KenD
>
>