natea
commented
6 years ago Even after using USERID=1000 make cms and re-running the update_assets paver command, I still get the same error.
Closed natea closed 6 years ago
natea
commented
6 years ago Even after using USERID=1000 make cms and re-running the update_assets paver command, I still get the same error.
regisb
commented
6 years ago This is a case where /dev/null eats the actual error. Can you try to run python manage.py lms --settings=development print_settings STATIC_ROOT --format=value to find the real error?
natea
commented
6 years ago Here's the output when I run that command:
root@dec35919721e:/openedx/edx-platform# python manage.py lms --settings=development print_settings STATIC_ROOT --format=value
Traceback (most recent call last):
File "manage.py", line 111, in <module>
startup = importlib.import_module(edx_args.startup)
File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
__import__(name)
File "/openedx/edx-platform/lms/startup.py", line 12, in <module>
settings.INSTALLED_APPS # pylint: disable=pointless-statement
File "/usr/local/lib/python2.7/dist-packages/django/conf/__init__.py", line 48, in __getattr__
self._setup(name)
File "/usr/local/lib/python2.7/dist-packages/django/conf/__init__.py", line 44, in _setup
self._wrapped = Settings(settings_module)
File "/usr/local/lib/python2.7/dist-packages/django/conf/__init__.py", line 92, in __init__
mod = importlib.import_module(self.SETTINGS_MODULE)
File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
__import__(name)
ImportError: No module named developmentSince I used the EDX_PLATFORM_VERSION environment variables, why when I run make lms is it showing that the edx-platform repo is using the one from edX?
Did I forget a re-build step along the way?
root@dec35919721e:/openedx/edx-platform/lms/envs# git remote -v
origin https://github.com/edx/edx-platform.git (fetch)
origin https://github.com/edx/edx-platform.git (push)
root@dec35919721e:/openedx/edx-platform/lms/envs# git branch
* open-release/ginkgo.masterBut even if I change it to use my fork, I forgot to check in the two development.py files into my forked repo, so even after I change the repo, it's still not going to find the development.py file.
regisb
commented
6 years ago There is a misunderstanding: EDX_PLATFORM_VERSION is a docker argument, not an environment variable. If you wish to define a different EDX_PLATFORM_VERSION then you need to modify the docker-compose.yml file accordingly (here is the documentation). Instructions about this are purposedly scarce in the README because it's a rather advanced feature.
EDIT: and of course, you would need to add a development.py module in the lms/envs and cms/envs folder of your repo to get it to work in development mode.
natea
commented
6 years ago Sorry, my memory failed me. I meant to type EDX_PLATFORM_REPOSITORY, Which should be my forked repo URL which should match the repo that is checked out to EDX_PLATFORM_PATH, right?
regisb
commented
6 years ago EDX_PLATFORM_REPOSITORY, just like EDX_PLATFORM_VERSION, is also a docker argument, not a docker environment variable. As such, it is only useful during build, not at runtime. Thus, there is no need to define these two arguments when you try to run make lms or make cms.
I realise now that giving instructions about image building is confusing. In the near future images will be downloadable from hub.docker.com and you won't have to build anything locally yourself.
natea
commented
6 years ago Ok, now I'm very confused because 2 days ago you said that these variables are not used during build, only at runtime, and now you're saying that they only useful during build, not at runtime. :/
Can you help me understand which variables are used during build and which are used during runtime?
regisb
commented
6 years ago Ok, my comment was confusing:
EDX_PLATFORM_PATH and EDX_PLATFORM_SETTING are environment variables used at runtime only EDX_PLATFORM_REPOSITORY and EDX_PLATFORM_VERSION are docker args used at build only
natea
commented
6 years ago ok, that makes sense now! Thanks :)
natea
commented
6 years ago @regisb one question since I'm new to using a volume on my mac for edx-platform but having the actual runtime in a Docker container.
Under what circumstances would I need to rebuild the images? If I want to install a new XBlock or add something that has to go into the Python environment then I would need to rebuild the image, whereas if I'm just making SASS or template changes, then that would not require the rebuilding of the image?
regisb
commented
6 years ago Since we are talking about docker volumes, I assume you mean working on Open edX during development.
If I want to install a new XBlock or add something that has to go into the Python environment then I would need to rebuild the image
Correct. Unless the requirement is in the edx-platform repo itself, such as the requirements from local.txt. Another option is to reinstall the requirement every time you start the container, but that is just painful.
if I'm just making SASS or template changes, then that would not require the rebuilding of the image?
No, it would not, because asset collection is not part of the build process.
When I try to run
paver update_assets cms --settings=developmentto update the CMS assets, I get the following error. Do I need to run it withUSER=1000 make cmsinstead?