240
edits
OctConf 2018 Notes: Difference between revisions
→Talking: Octave Forge community
(→Talking: Octave Forge community) |
|||
| Line 45: | Line 45: | ||
; Octave Forge community | ; Octave Forge community | ||
: To increase the pool of high-level users we need to reduce even more the burden to install and distribute packages independently. To do this we bring back the idea of allowing `pkg` to download and install directly from a url to a `.zip` file or `.tar.gz` file, e.g. `pkg install 'https://myrepo.org/mypackage.zip'` | Currently, there is a high barrier to publish new packages for Octave on Octave-Forge. This mainly comes from the maintenance burden that the Octave Forge Community has with the packages. In particular: | ||
* The package has to be actively maintained in order to stay compatible with updates to Octave core | |||
: | * There is no known good solution to have a Matlab-compatible package, which respects the requirements of an OF package | ||
* The list of initial requirements (legal and technical) is quite high for outside contributers, especially for domain experts (which we want to address) who are no software engineers | |||
This creates problems for some external package authors, who basically want to release on their own. Also, this is not resolved by the *two package groups* that we have introduced during the last year. | |||
We see potential for more Octave package publications, which come from “one-off” publications (e. g. with a book / thesis), existing Matlab packages (which also offer a Octave variant), and simple (experimental) libraries of m-files. To increase the pool of high-level users we need to reduce even more the burden to install and distribute packages independently. | |||
The problem that we see today is that Octave-Forge is two-fold: (1) a (collaborative) software development platform and (2) a (re-)distributor of software. So, these new use-cases would not be part of Octave-Forge. In the context of an increasing number of independent “Github developers” this is not needed so much. | |||
To do this we bring back the idea of allowing `pkg` to download and install directly from a url to a `.zip` file or `.tar.gz` file, e.g. `pkg install 'https://myrepo.org/mypackage.zip'` | |||
* There will be no checks (nor quality standard) on these packages and the user should be clearly warned: | |||
** Security issue: With no https the download can be redirected. The user can be tricked into entering this command, which downloads and installs (=runs) arbitrary software. | |||
** Feedback/QA issue: If that package doesn't work, users are probably asking for help. | |||
* Should `pkg update` also work for these packages? | |||
** Maybe no. Just re-run the install command. | |||
** If needed, there could be an update url in the DESCRIPTION file | |||
* We need to provide guidelines, recommendations and tools for people trying to distribute their packages. We are doing something in this direction, but we need a little boost here: https://octave.sourceforge.io/templates/Makefile, https://sourceforge.net/p/octave/example-package/ci/default/tree/ | |||
* If a package can be installed directly from the repository, it would be supported out-of-the-box by Github, Gitlab, … | |||
Also, we discussed a “package database” like it is done in Julia (see [https://github.com/JuliaLang/METADATA.jl] for a very lightweight solution, which only contains package names, URLs and version), but don't see advantages from that right now. | |||
; packages into Octave core | ; packages into Octave core | ||