> On 2019-08-26, at 1:33 AM, Tobias Pape <Das.Linux at gmx.de> wrote:
[snip]
>  And it returns an empty list for 
>> Installer lukas basicAvailablePackages 
> 
> That's because it isn t a single repository but a collection thereof, just like squeaksource.

Ah, a quick pass in the degubber suggests that something is not working as expected by the package listing code. The repository pointed to by #lukas is MCHttpRepository(http://source.lukas-renggli.ch), which when sent the usual #allfileNamesOrCache returns a reasonable looking list of  stuff like 'magritte3addons/' 'pier/' '/built/oneclick/Pier-1.0-OneClick.zip' 'pieraddons/' 'pier2/' '/built/oneclick/Pier-2.0-OneClick.zip' (just grabbing a few entries from the middle of the list).

However, when the code checks for those results being valid they all fail the test in #isValid., which is why we get an apparently empty list of available packages. 

Now the interesting thing is that it looks like this is a general issue for squeaksource and ss3 websites, at least. But my local package-cache MC returns a perfectly good list of packages. It looks like we have a minor design bug getting in the way here; for the `Installer cache availablePackages` case we end up running MCFileBasedRepository>>#validNames: and since the items in the package-cache directory are very 'ordinary' filenames it works. 
When trying `Installer ss availablePackages` we still run MCFileBasedRepository>>#validNames: but all the items returned are not at all the same format as package names. They are more like '/@kUVwlQhgbjCHrPSQ/8sV_cJ_-?18' - which I'm going to ascribe for the moment to Seaside. Clearly these sort of 'filenames' aren't going to return true when sent #isValid.

We're well out in the weeds from where I was intending to work on this but maybe someone with interest and experience in details of MC/squeaksource can work out a way to derive more appropriate names. Perhaps a more squeaksource specific repository class could over-ride #allFileNames or #parseFileNamesFromString: (like the file tree specific class does) to solve the problem. At least maybe we could over-ride to deliberately do nothing and not waste time fetching info we know isn't useful.

Generically, surely it would be helpful to have all the repository types able to list what projects/packages they can provide? Nice simple discovery always seems to be useful.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Useful random insult:- Doesn't just know nothing; doesn't even suspect much.