octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GSoC 2017


From: Juan Pablo Carbajal
Subject: Re: GSoC 2017
Date: Mon, 30 Jan 2017 11:31:30 +0100

On Mon, Jan 30, 2017 at 7:49 AM, Sebastian Schöps <address@hidden> wrote:
> Dear Nir,
>
>> Also please edit the ideas page so it's up to date
>> http://wiki.octave.org/Summer_of_Code_Project_Ideas
>
> I have slightly extended Carnë's pkg proposal [1] after an offline discussion 
> with him (installation of packages from URLs or repositories and added 
> additional mentors). This project has been included to the summary table.
>
> Bye
> Sebastian
>
> [1] 
> http://wiki.octave.org/Summer_of_Code_Project_Ideas#Octave_Package_management

Hi all,

I edited the page to avoid suggesting that some advanced improvements
where more important than basic ones. The experience with the previous
attempt to improve pkg was that there was a growing set of
requirements that were low-level and user-invisible, only maintainers
would potentially felt those changes.
I took the freedom to focus the project more on the user experience of
pkg, rather than on the maintainers view.

I was never a fan of adding at first all that Octave multi-version,
global/local, user/system, etc flexibility. I understand it can be
useful, but I rather put it low in the order of things to do.
I think getting external packages, dealing with deps (this includes
package names decorated with their version, so "pkg load image -v 1.0"
is different than "pkg load image -v 2.0"), and passing make options
is far more important at this point.

I respect Carnë's devotion to high quality specifications, but
sometimes you have to account for man-power and available time,
therefore it is better to reduce demands and get things running, and
make sure that they are extendable.

Also, when installing from urls, I believe we just need to provide a
clear structure specification, so the work of installing the package
is minimal. Indeed we could start by asking that the url contains a
proper *.tar.gz that can be directly downloaded and installed. When
that's working we can add more flexibility and require just a proper
package structure, etc.... In this way the work is left to the creator
of that external package and not to us. It should be clear to the user
that when installing from urls we (GNU Octave community) do not take
any responsibility on what's installed (issuing a warning should be
necessary).

I added a link to Carnë's pkg bookmark where all subfunctions where
re-written and a uniform option parsing was defined (I think now
obsolete due to inputParser).

I hope we get  somebody interested in this project.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]