Could not open requirements file: [Errno 2] No such file or directory: '/requirements.txt' => my requirements.txt is in /code/ about nanobox-engine-python

[harobed]

Maybe this bug is in relation with #9 ?

[glinton]

@harobed this very well could be related to #9, though I don't see an expected error in the log. Can you confirm this is still an issue, then we can close it?

[harobed]

I would like to test it, but I can't use my python engine because I've this bug : nanobox-io/nanobox#95

[harobed]

Bug fixed after :

• nanobox update
• nanobox update-images
• and, important nanobox destroy

[harobed]

and, important nanobox destroy

This I think because /usr/local/bin/nanobox-server in vagrant isn't updated after nanobox update, what do you think about that @glinton @sdomino ?

[harobed]

I need also to use last nanobox-engine-python from git clone to get the last version elsewhere I've :

/opt/nos/lib/payload.sh: line 9: PL_error:: command not found

Are there a command to update native engine ? if not, it's possible to append nanobox update-engines ?

I keep this issue open because this bug isn't fixed « out of the box ».

[sdomino]

Nanobox tries not to mess with the Vagrantfile once it creates it, so adding an engine after it's been created would cause it not to be mounted. There are a few ways to get around this:

1. Like you mentioned, destroying the box and recreating it to regenerate the Vagrantfile (not ideal)
2. Deleting the Vagrantfile and running a command to regenerate it (not ideal)
3. Running "nanobox init -f" will regenerate it (this is ok, but "init" is a "hidden" command)

I think what we'll probably do is with a "nanobox reload" regenerate a new Vagrantfile since reload is kind of a last resort way of resetting your VM before destroying it and trying again.

---

As for update-engines, all that would basically do is a "git up" on the repo, which is probably something easier/better handled by you just manually running it to get the updates for w/e engine you happen to be using at the time.

[glinton]

@harobed The reason the bug wasn't fixed "out of the box" was because we failed to publish our python engine after fixing the issue (77cb95c). If I remember though, there may be one other place where this would be caused. I'm almost sure it's resolved though, but if you do see this again, please let us know.

Also, regarding @sdomino's comment about updating the engine yourself with a git pull, this should only be necessary if you are developing on the engine, using a custom engine, or manually testing a new, unpublished, addition to the engine. Nanobox will should be fetching the latest engine when you run|dev

[harobed]

What I do :

$ git clone https://github.com/harobed/nanobox-python-sample.git
$ cd nanobox-python-sample
$ nanobox destroy
$ nanobox  update
$ nanobox update-images
$ nanobox dev

I've got :

VIRTUALENV ENV ------------------------>
   New python executable in env/bin/python2.7
   Also creating executable in env/bin/python
   Installing setuptools, pip...done.
   [√] SUCCESS
   $ env/bin/pip install -r /opt/code/requirements.txt

PIP INSTALL --------------------------->
   You are using pip version 6.0.8, however version 7.1.2 is available.
   You should consider upgrading via the 'pip install --upgrade pip' command.
   Collecting flask (from -r /opt/code/requirements.txt (line 1))
     Downloading Flask-0.10.1.tar.gz (544kB)
   Collecting Werkzeug>=0.7 (from flask->-r /opt/code/requirements.txt (line 1))
     Downloading Werkzeug-0.11.2-py2.py3-none-any.whl (304kB)
   Collecting Jinja2>=2.4 (from flask->-r /opt/code/requirements.txt (line 1))
     Downloading Jinja2-2.8-py2.py3-none-any.whl (263kB)
   Collecting itsdangerous>=0.21 (from flask->-r /opt/code/requirements.txt (line 1))
     Downloading itsdangerous-0.24.tar.gz (46kB)
   Collecting MarkupSafe (from Jinja2>=2.4->flask->-r /opt/code/requirements.txt (line 1))
     Downloading MarkupSafe-0.23.tar.gz
   Installing collected packages: MarkupSafe, itsdangerous, Jinja2, Werkzeug, flask
     Running setup.py install for MarkupSafe
       building 'markupsafe._speedups' extension
       gcc -fno-strict-aliasing -O2 -Wno-error -I/usr/include/x86_64-linux-gnu -DHAVE_DB_185_H -pthread -I/usr/include -I/data/include/db4 -I/data/include -I/data/include/ncurses -DNDEBUG -O2 -Wno-error -I/usr/include/x86_64-linux-gnu -DHAVE_DB_185_H -pthread -I/usr/include -I/data/include/db4 -I/data/include -I/data/include/ncurses -fPIC -I/data/include/python2.7 -c markupsafe/_speedups.c -o build/temp.linux-x86_64-2.7/markupsafe/_speedups.o
       gcc -shared -L/var/tmp/pkgsrc-build-base/base/python27/work/Python-2.7.10 -L/lib/x86_64-linux-gnu -L/usr/lib/x86_64-linux-gnu -pthread -L/data/lib -Wl,-R/data/lib build/temp.linux-x86_64-2.7/markupsafe/_speedups.o -L/data/lib -lpython2.7 -o build/lib.linux-x86_64-2.7/markupsafe/_speedups.so
     Running setup.py install for itsdangerous
     Running setup.py install for flask
   Successfully installed Jinja2-2.8 MarkupSafe-0.23 Werkzeug-0.11.2 flask-0.10.1 itsdangerous-0.24
   [√] SUCCESS

Ok this bug is fixed :)