Re: URL for forge packages

[Juan Pablo Carbajal]

On Fri, Aug 17, 2012 at 8:30 AM, Thomas Yengst <address@hidden> wrote:
>>
>> On 16 August 2012 13:14, Carn? Draug <address@hidden> wrote:
>>> Hi
>>>
>>> the current method to get the URL for packages when installing with
>>> the -forge flag is to parse the HTML of the package for the version
>>> and use it to generate a URL to download it. I see two problems with
>>> this:
>>>
>>> 1. if we are to change the format of the documentation page this will
>>> start failing
>>> 2. if we move the packages to another host (as has been discussed
>>> before), it will also fail
>>>
>>> While such changes are not planned to happen on OF soon, when they do
>>> it will mean that users using octave versions before the change won't
>>> be able to use the -forge flag. I think to prevent this before becomes
>>> an issie it's a good idea.  I would like to propose to have a simple
>>> text file on octave.org with this info. 1 line with package names and
>>> their URLs would suffice. This would also make the code to get
>>> packages from forge simpler since the parsing would also be simpler.
>>>
>>> Any comments?
>>
>> I gave this some more thought and here's the solution I propose. The
>> idea will be to have a text file in octave.org that is automatically
>> updated with a file I'll set up in SF. The following syntax for such
>> file would allow for other projects similar to Octave Forge (if and
>> when they appear) to also have their -project flag in pkg.
>>
>> =Forge http://path-text-file-with-list-of-forge-packages
>> package1-name package1-version package1-url
>> package2-name package2-version package2-url
>> package3-name package3-version package3-url
>> =ProjectX http://path-text-file-with-list-of-projectx-packages
>> package1-name package1-version package1-url
>>
>> Basically, the word after the equal would be the project and flag used
>> to get packages, followed by a URL for a text file that is
>> responsibility of that project. That text file would have just the
>> project, version, and url lines. Should be pretty simple for a perl
>> script to routinely check those URL's for changes and edit the file on
>> octave.org.
>>
>> I'd guess that XML would be better but having to parse them in Octave
>> is more complicated and I don't think we need that.
>>
>> Any comments? Can I start writing such scripts?
>>
>
> I think XML is overkill - a self explanatory text file is easier to implement 
> and easier to read.
>
> I would assume that one could then just change the url's to local file system 
> url - like file://data/stuff/io-1.0.9.tgz?
> It is important to be able to use a directory full of packages on a local 
> file system. My enterprise setup does not have the cluster computers 
> connected to the internet, only to the company LAN (for a lot of reasons). 
> It's much easier to maintain all the Forge packages if I can download them 
> all and do an install of them all with one command.
>
> Tom

Carne,

I agree with Soren, we should use internal format if possible.

Indeed, I would suggest to store a struct as it is done in
.octave_packages in the user folder. This will also ease the merging
of and update of that file.

m2c.


-- 
M. Sc. Juan Pablo Carbajal
-----
PhD Student
University of Zürich
http://ailab.ifi.uzh.ch/carbajal/