kadi web branch django can't run without all installed_apps

[jeanconn]

Is there a way to keep the web branch running even if a runtime doesn't have all requested apps?

ska-fido: python manage.py runserver
Traceback (most recent call last):
  File "manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File "/proj/sot/ska/arch/x86_64-linux_CentOS-6/lib/python2.7/site-packages/django/core/management/__init__.py", line 399, in execute_from_command_line
    utility.execute()
  File "/proj/sot/ska/arch/x86_64-linux_CentOS-6/lib/python2.7/site-packages/django/core/management/__init__.py", line 392, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/proj/sot/ska/arch/x86_64-linux_CentOS-6/lib/python2.7/site-packages/django/core/management/base.py", line 242, in run_from_argv
    self.execute(*args, **options.__dict__)
  File "/proj/sot/ska/arch/x86_64-linux_CentOS-6/lib/python2.7/site-packages/django/core/management/base.py", line 280, in execute
    translation.activate('en-us')
  File "/proj/sot/ska/arch/x86_64-linux_CentOS-6/lib/python2.7/site-packages/django/utils/translation/__init__.py", line 130, in activate
    return _trans.activate(language)
  File "/proj/sot/ska/arch/x86_64-linux_CentOS-6/lib/python2.7/site-packages/django/utils/translation/trans_real.py", line 188, in activate
    _active.value = translation(language)
  File "/proj/sot/ska/arch/x86_64-linux_CentOS-6/lib/python2.7/site-packages/django/utils/translation/trans_real.py", line 177, in translation
    default_translation = _fetch(settings.LANGUAGE_CODE)
  File "/proj/sot/ska/arch/x86_64-linux_CentOS-6/lib/python2.7/site-packages/django/utils/translation/trans_real.py", line 159, in _fetch
    app = import_module(appname)
  File "/proj/sot/ska/arch/x86_64-linux_CentOS-6/lib/python2.7/site-packages/django/utils/importlib.py", line 40, in import_module
    __import__(name)
ImportError: No module named find_attitude.web

[taldcroft]

There is a way, which is dynamically look for apps and conditionally add them in INSTALLED_APPS and urls.py. It's not that hard, but what I'm worried about is that this leaves the production site vulnerable to being broken when failed imports are ignored. In this case something like the find_attitude utility might not be available but we wouldn't know it without actually trying it.

So then you need more code to distinguish between test and production, and then it starts looking like too much.

[taldcroft]

Closed by 55c61deb9e, which outlines a procedure that should reliably allow imports of all dependencies.

[jeanconn]

What channel is supposed to provide pyyaks to use the conda test setup directions?

[taldcroft]

That would be ska, but of course that channel is out of date. So the "low-fidelity" test is not really an option now, I think.

[jeanconn]

That would be ska, but of course that channel is out of date. So the "low-fidelity" test is not really an option now, I think.

For the time being, I was thinking about updating the directions to just suggest cloning a root dev ska .

[taldcroft]

The three words clone, root, and dev seem a bit contradictory and leave me confused. Do you mean more like "make a dev ska"?

[jeanconn]

The three words clone, root, and dev seem a bit contradictory and leave me confused. Do you mean more like "make a dev ska"?

I meant

conda create -n mykadi --clone root

from my dev ska so I'd still have a flight copy dev ska but would make an env in an area I can write.

[taldcroft]

I didn't realize that cloning like this also gets the pip-installed packages. (I don't understand how that can work, but I believe it does). So your process will work, but the more I think the more I prefer option 1 since it faithfully replicates how the deployed site is actually run using PYTHONPATH + flight Ska. Using your dev ska means trusting that it is up to date.

[jeanconn]

I didn't realize that cloning like this also gets the pip-installed packages. (I don't understand how that can work, but I believe it does).

I was also surprised, but when I saw that it seemed to work with the pip-installed packages I was sold on it as a possible solution.

So your process will work, but the more I think the more I prefer option 1 since it faithfully replicates how the deployed site is actually run using PYTHONPATH + flight Ska. Using your dev ska means trusting that it is up to date.

Right, but that's not that much of a stretch if my plan is to keep the root dev ska at flight and do any playing and updates in separate conda environments.

[taldcroft]

Right, but that's not that much of a stretch if my plan is to keep the root dev ska at flight and do any playing and updates in separate conda environments.

OK, but you need to add to the procedure to explicitly do a full update of the dev ska root at the time of doing testing in order to be sure. For instance I might have updated a package in skare by github edit and forgotten to mention it.

[jeanconn]

OK, but you need to add to the procedure to explicitly do a full update of the dev ska root at the time of doing testing in order to be sure. For instance I might have updated a package in skare by github edit and forgotten to mention it.

Do we have notes for how to do a full update? A "make all" isn't going to work anyway, right, because anaconda doesn't have an overwrite install mode. Did you have in mind something like

conda install --file=pkgs.conda
make python_modules

as a process?

[taldcroft]

What you wrote is probably right. I would still vote for using PYTHONPATH in this particular case as being simpler, faster, and more accurate. Just install the web branches of kadi and mica into the PYTHONPATH dir and it's done.

[taldcroft]

I made some updates in d59e6d8.