Opened 8 years ago

Closed 3 years ago

#1652 closed enhancement (fixed)

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

Reported by: mlennert Owned by: grass-dev@…
Priority: normal Milestone: 7.2.1
Component: Addons Version: unspecified
Keywords: g.extension, addon, extensions, compilation, installation Cc:
CPU: Unspecified Platform: Unspecified

Description

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

Attachments (2)

gextension-local.diff (3.1 KB) - added by wenzeslaus 5 years ago.
Draft implementation of compilation of local source code
g.extension.py (34.5 KB) - added by wenzeslaus 5 years ago.
g.extension with the draft implementation included

Download all attachments as: .zip

Change History (11)

comment:1 Changed 8 years ago by 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.

comment:2 in reply to:  1 Changed 8 years ago by 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

Changed 5 years ago by wenzeslaus

Attachment: gextension-local.diff added

Draft implementation of compilation of local source code

Changed 5 years ago by wenzeslaus

Attachment: g.extension.py added

g.extension with the draft implementation included

comment:3 Changed 5 years ago by 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...

comment:4 Changed 5 years ago by wenzeslaus

Component: InstallationAddons
Keywords: extensions compilation installation added
Milestone: 7.0.07.1.0

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.

comment:5 Changed 5 years ago by 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).

comment:6 Changed 4 years ago by 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).

comment:7 Changed 4 years ago by neteler

Milestone: 7.1.07.2.0

Milestone renamed

comment:8 Changed 3 years ago by neteler

Milestone: 7.2.07.2.1

Ticket retargeted after milestone closed

comment:9 Changed 3 years ago by wenzeslaus

Resolution: fixed
Status: newclosed

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).

Note: See TracTickets for help on using tickets.