g.extension: provide option to use local source code instead of SVN

[mlennert]

It would be a nice addition to g.extension to allow the use of local source code (e.g. a local directory) for the installation of a module. This would provide a unified way of installing extensions, even those one does not, yet, see fit for public distribution.

Moritz

[hamish]

? both source URL and compiled destination are configurable through the svnurl= and prefix= options.

The GRASS_ADDON_PATH environment variable is also respected if it is set.

Is there something else which would be helpful to use beyond that? e.g. avoid having to set svnurl=​http://localhost/something and instead do srcdir=/path/to/...? In that case why not just set up an alias:

alias gmake65='make MODULE_TOPDIR=/usr/src/grass/svn/grass65/'

and then run gmake65 from your source dir?

Hamish

ps- I think it's a fine thing to use the addons repo as a module incubation & development area; my method is to simply not activate the Makefile until it's ready for wider consumption. see also the grass sandbox repo for personal (but open) experimentation.

[mlennert]

Replying to hamish:

? both source URL and compiled destination are configurable through the svnurl= and prefix= options.

The GRASS_ADDON_PATH environment variable is also respected if it is set.

Is there something else which would be helpful to use beyond that? e.g. avoid having to set svnurl=​http://localhost/something and instead do srcdir=/path/to/...? In that case why not just set up an alias:

alias gmake65='make MODULE_TOPDIR=/usr/src/grass/svn/grass65/'

and then run gmake65 from your source dir?

Having a unified tool makes it easier for newbies. Using g.extension the user does not have to think about MODULE_TOPDIR.

svnurl=​http://localhost/something implies a web server on localhost, no ? Again an unnecessary hurdle IMHO.

The question came up on the French user's list where someone would like to use the r.traveltime addon which is not in svn. It would be nice to be able to tell such a user to just download the .tgz, and then tell g.extension where to find it and have g.extension handle the rest.

In this particular case, the authoer of the addon has agreed to put it on the svn server which I hope to have the time for end of the week or next week.

Moritz

[wenzeslaus]

Draft implementation of compilation of local source code

[wenzeslaus]

g.extension with the draft implementation included

[wenzeslaus]

I've added a first draft of implementation of compilation of local source code and its installation where it belongs. New code are few changes in compilation function, new parameter and interception of standard flow and executing the compile and install step without executing other things.

No error handling included. Except for MS Windows where it should fail. But the interesting problem is that it should not fail for Python since there is no reason for Python code to not be installed. But this requires us to implement installation procedure of Python modules in Python instead of Makefile.

Tested with a module in already downloaded SVN repository.

g.extension extension=i.edge operation=add srcdir=/some/source/code/addons/grass7/imagery/i.edge

Instaling <i.edge> from directory </some/source/code/addons/grass7/imagery/i.edge>...
Compiling...
Installing...

[wenzeslaus]

I've tested the proposed version of g.extension and it works for me on both Ubuntu and Mac OS X. On Mac tested with both self-compiled and installed GRASS (packaged by Michael Barton).

GRASS... > chmod u+x ~/Downloads/g.extension.py
GRASS... > ~/Downloads/g.extension.py extension=r.ptest srcdir=~/Downloads/r.ptest/

I did not checked on Mac but on Ubuntu it was installed to ~/.grass7/addons and the modules.xml file was not updated, I don't know if this is OK or not and what is influenced.

In case of an error, there should be some suggestion to user to try to install something from addons (some C module, e.g. r.geomorphon) to see if the compilation works in general.

[wenzeslaus]

As noted before, on MS Windows, Python modules could be compiled and this relates to the solution of running Python on MS Windows problem where the possible way is to use BAT files. g.extension run in this case would generate the BAT file. g.extension can even generate BAT file and Makefile itself since it is pretty clear what should be in them (this applies even to C modules).

[wenzeslaus]

Please, try the version in trunk (7.1) which supports local directories besides ​many other options. This was not tested on MS Windows as we still lack the functionality described in the comment:5, i.e. (Python-based) compilation of (at least) Python code or alternatively, we could add flag to force the unix behavior (for users who have the environment ready).

[neteler]

Milestone renamed

[neteler]

Ticket retargeted after milestone closed

[wenzeslaus]

This is solved for the developer-friendly systems. There is a ticket #3298 for MS Windows support. So, closing this one. Please open a new ticket if you miss some particular feature.

Moreover, on all platforms Python scripts now get GUI (#2133, r67993, r67994) even if they are not installed on standard path. Plus there is the Python editor which targets beginners and does not require any compilation to "just run the code" (r67972).