webapp not loading / after fresh install

[pvavra]

I'm running into issues similar to #98. In a new hirni-dataset, the webapp does not load at all.

current install uses datalad 0.12.rc4, hirni 0.0.4, webapp 0.2

To reproduce, should be possible to run:

datalad create test_webapp
cd test_webapp
datalad cfg_hirni
datalad run-procedure cfg_hirni
datalad webapp

I doubt that is related, but for completeness: I'm running the above on medusa, and using ssh -L 5000:localhost:5000 [..]to forward the port to my local machine. In my browser, I call localhost:5000and see the HTTP request being received on medusa, but giving the following error (see last line):

datalad webapp                
[WARNING] Available webapp resource'auth' 
[WARNING] Available webapp resource'file' 
[WARNING] Available webapp resource'procedure' 
[WARNING] Available webapp resource'subdataset' 

*************************************************
*************************************************

      THIS IS NOT A PRODUCTION-READY TOOL

      - only use in a trusted environment
      - do not expose service on public
        network interfaces

*************************************************
*************************************************

 * Serving Flask app "datalad_webapp" (lazy loading)
 * Environment: production
   WARNING: This is a development server. Do not use it in a production deployment.
   Use a production WSGI server instead.
 * Debug mode: off
 * Running on http://127.0.0.1:5000/ (Press CTRL+C to quit)
127.0.0.1 - - [03/Dec/2019 18:38:43] "GET / HTTP/1.1" 404 -

[bpoldrack]

Huh. That's interesting. Will try to replicate.

[pvavra]

was using python 3.6.9 -- in case that makes some difference.

If you need any more info on the setup, let me know.

[pvavra]

so, turns out this is simply issue #98. I was erroneously running datalad webapp without the hirni argument at the end..

with the correct call, it doesn't find the sub-folders with the js and css files..

i.e.:

127.0.0.1 - - [04/Dec/2019 16:42:50] "GET / HTTP/1.1" 200 -
127.0.0.1 - - [04/Dec/2019 16:42:50] "GET /css/bootstrap.min.css HTTP/1.1" 404 -
127.0.0.1 - - [04/Dec/2019 16:42:51] "GET /css/open-iconic-bootstrap.min.css HTTP/1.1" 404 -
127.0.0.1 - - [04/Dec/2019 16:42:51] "GET /js/jquery.slim.min.js HTTP/1.1" 404 -
127.0.0.1 - - [04/Dec/2019 16:42:51] "GET /js/bootstrap.bundle.min.js HTTP/1.1" 404 -
127.0.0.1 - - [04/Dec/2019 16:42:51] "GET /js/axios.min.js HTTP/1.1" 404 -

[bpoldrack]

Ah, okay. So, as stated in #98 this happens if you install hirni from github rather than from Pypi. The released version gets those files packaged. Installing from github results in a clone, which generall is fine, but pip doesn't know anything about git-annex and won't get those files first. Therefore if installing via cloning a git annex get . is needed in addition.

We can't really do anything about that other than getting the next release ready and put a note in the README in here.

[pvavra]

on a fresh clone, this does not work. the web cannot be reached -- did the path change maybe?

any ideas?

git clone https://github.com/psychoinformatics-de/datalad-hirni.git

...

cd datalad-hirni

git annex get . 
(merging origin/git-annex into git-annex...)
(recording state in git...)
get datalad_hirni/resources/webapp/css/bootstrap.min.css 
  Remote origin not usable by git-annex; setting annex-ignore
(from web...) 
(checksum...) ok
get datalad_hirni/resources/webapp/css/open-iconic-bootstrap.min.css (from web...) 
(checksum...) ok
get datalad_hirni/resources/webapp/fonts/open-iconic.svg (from web...) 
(checksum...) ok
get datalad_hirni/resources/webapp/fonts/open-iconic.ttf (from web...) 
(checksum...) ok
get datalad_hirni/resources/webapp/fonts/open-iconic.woff (from web...) 
(checksum...) ok
get datalad_hirni/resources/webapp/js/axios.min.js (from web...) 

  verification of content failed

  Unable to access these remotes: web

  Try making some of these repositories available:
    00000000-0000-0000-0000-000000000001 -- web
    71680918-77ae-4be1-9128-e72e87aa180a -- mih@meiner:~/hacking/cbbs-imaging/datalad-hirni
    b9f8960a-e81a-4a77-ad0c-41c996331c94 -- aqw@brick:~/git/datalad-hirni

  (Note that these git remotes have annex-ignore set: origin)
failed
get datalad_hirni/resources/webapp/js/bootstrap.bundle.min.js (from web...) 
(checksum...) ok
get datalad_hirni/resources/webapp/js/jquery.slim.min.js (from web...) 
(checksum...) ok
get datalad_hirni/resources/webapp/js/vue.min.js (from web...) 
(checksum...) ok
(recording state in git...)
git-annex: get: 1 failed

[pvavra]

So, I'm obviously not understanding about git annex here.. Given the annex-ignore set: origin message (and a brief google search), I figured that setting git config remote.origin.annex-ignore false should work. But git annex get . resets origin to be ignored again..

[bpoldrack]

That git-annex-ignore setting is fine as is. origin is a git remote (GitHub) that doesn't provide any store for annexed content. So annex correctly ignores that remote. The annex builtin special remote web is where things should come from indeed. That means, it is just downloading from internally registered URLs (originally done via simple git-annex-addurl). Obviously that works for everything but axios.min.js suggesting, that that particular URL wasn't reachable.

[bpoldrack]

datalad-hirni$ git annex whereis datalad_hirni/resources/webapp/js/axios.min.js 
whereis datalad_hirni/resources/webapp/js/axios.min.js (4 copies) 
        00000000-0000-0000-0000-000000000001 -- web
        16247b61-1e47-408a-92ff-d7329ce7e1fb -- ben@tree:~/work/hacking/datalad-hirni [here]
        71680918-77ae-4be1-9128-e72e87aa180a -- mih@meiner:~/hacking/cbbs-imaging/datalad-hirni
        b9f8960a-e81a-4a77-ad0c-41c996331c94 -- aqw@brick:~/git/datalad-hirni

  web: https://raw.githubusercontent.com/axios/axios/master/dist/axios.min.js
ok

So, that last line shows the URL being used for it. And generally that URL still works (for me): https://raw.githubusercontent.com/axios/axios/master/dist/axios.min.js

However, there is another line in your above post:

verification of content failed

Now, that might be our fault. We linked into the master branch of axios instead of a particular commit. So, if there was a change, the checksum would be different. And that might be what's going on here. annex figures that the file it got from that URL is not the file it expected to get as by its checksum.

I'll verify that thesis and fix it. Thanks much for examining further!