[NLPL Task Force (A)] clarification of NLPL installation guide

[Tiedemann, Jörg]

Hi,

Thanks, Stephan, for the updates and my apologies that I had to leave the call so quickly.
Below some comments about the issues that you mentioned.

> 
> + in my view, we should religiously avoid soft links; there should be
> one unique path that refers to each resource.  for example, it should
> either be ‘opus’ or ‘OPUS’, but not both.  since the guide requires
> all lower-case, how difficult would it be to make it
> ‘$NLPL/data/opus/’ still?

In that case I would go for OPUS with upper-case letters. Otherwise various scripts would break and I don’t want to go through the entire setup to check that nothing is affected by a name-change. This is especially for OPUS on taito where I will use those procedures to convert & process data sets. Within OPUS, there will be in any case sub-directories with upper-case letters as well and OPUS also does not follow the 3-letter standard of language IDs as recommended by nlpl. Another thing I will not change (at least for the time being). I will remove the symbolic after checking that nothing breaks. I’ll try to do that some time before Christmas.

> 
> + i think there should be a direct correspondence between the module
> name and its location: for example, the ‘nlpl-opus’ module should have
> its associated binaries and data below $NLPL/software/opus/ (not
> ‘opus-tools’, unless the module were called ‘nlpl-opus-tools’).

I would not go for that solution as modules can cover several pieces of software. In my cases, I used the original repository names at this point, which makes more sense to me. For example, the nlpl-opus module does not only load ‘opus-tools’ but also also cwb, uplug, letsmt, pdf2xml and subalign. 

> 
> + it appears there is a ‘stray’ installation of perl in the top-level
> ‘software/’ directory, i.e. ‘bin/’, ‘lib64/’, ‘man/’, and ‘share/’.
> my initial reaction is that these directories should not be there.  i
> know little about perl, but i am guessing we might need additional
> modules besides what comes with the system-wide perl module?  if so,
> my gut feeling still would be that these should somehow be packaged as
> a module ‘nlpl-perl’, parallel to everything else.  would that be
> possible?  a bit like a virtual environment in python?

In principle I agree. I will have a look into this to see if I can move them to some better location like nlpl-perl (or maybe a more general name like nlpl-common?). The thing is that some installations have pre-requisites that are installed automatically if they are missing and that happens to be in the software root now because (as you’ve guessed correctly) I used that directory as HOME when running the build-scripts. I tried to create a small script that sets a clean environment to avoid problems with my local settings when installing software (build_scripts/clean-env.sh). It’s similar to the things in (build_scripts/Makefile.common) that I include in build_scripts. Suggestions for those setting are welcome.

> 
> + i see there are personal dirctories ‘.subversion’, ‘.emacs.d’,
> ‘.gitconfig’, etc. inside $NLPL/software.  i am guessing somehow that
> directory served as your $HOME at some point, but in my view those
> user-specific directories should not be there.

See above - and I will try to get rid of those as well. Maybe I can set a temporary directory as HOME when installing software. Would it be enough to set it to ‘nlpl-common’ as suggested above to store general libraries and modules?

In any case, I will look into this soon but probably not within the next two weeks but rather in the week before Christmas.
Thanks for the suggestions in any case.

Jörg



> 
> —so much with the nit-picking tonight :-).  sorry to mostly targeting
> you, joerg!  but i hope the perfectionist in you may nevertheless kind
> of appreciate the feedback?
> 
> all best, oe
>