Circular dependence to bob.blitz during testing

This package depends on bob.blitz to run its test units. This is a problem in test environments (like conda packaging) where package downloading via setuptools is forbidden. We need to fix these tests by creating units which independent from other packages entirely. For the time being, such tests are skipped when bob.extension's conda package is built with --exclude=test_extensions. See logs with problem at bob/bob.conda!62.

The test bob.extension.test_utils:test_documentation_generation also has dependences on both bob.extension itself and gridtk. Why are we testing this?

https://gitlab.idiap.ch/bob/bob.extension/blob/master/bob/extension/test_utils.py#L131 only assures that we can link against the documentation that is available online. In fact, I think it does not create a dependency on bob.extension or gridtk. It just tries to link to the documentation of these two packages on pythonhosted.org and the Idiap docs server.

However, this test might fail when there is no internet connection.

For the first test, i.e., testing that we can install packages such as bob.blitz using setuptools, it might be that we want to skip this test when we are in a conda environment. This test is meant to test that our installation instructions in the documentation: https://www.idiap.ch/software/bob/docs/latest/bob/bob.extension/master/buildout.html still works.

Actually, to avoid circular dependencies, we might add a simple test package, which includes C++ and Python code, and which is linked in the test. In fact, we have such packages inside bob.extension, see: https://gitlab.idiap.ch/bob/bob.extension/tree/master/examples We could upload these to PyPI (or better, to our own package server) and query these instead.

Conda package building is a bit picky with downloading dependencies from remote urls. The reasoning is that all deps should be described in the meta.yaml file.

I think it would be nicer to have these example packages just lie there, in a data subdirectory inside bob.extension module. Firstly, they are shipped with the package and can be properly documented and explained. Secondly, it simplifies maintenance - today, the developer needs to modify the packages in the examples directory and then remember to update them on the package directory. These tarballs are not usable from a documentation perspective.

The examples should be self contained - except for buildout stuff and not depend on external packages.

I think, the examples are already in the data directory, as a tarball. At least, the script https://gitlab.idiap.ch/bob/bob.extension/blob/master/examples/update_examples.sh would put them there.

I agree that the tarballs are useless for the documentation generation test, but they are used inside the documentation, i.e.: https://www.idiap.ch/software/bob/docs/latest/bob/bob.extension/master/guide.html#anatomy-of-a-buildout-python-package Hence, I don't think that we can get rid of the tarballs.

Furthermore, we use the tarballs in some of our tests: https://gitlab.idiap.ch/bob/bob.extension/blob/master/bob/extension/test_extensions.py#L63 I think, these are the ones that we talk about in this issue...

I find it impractical that updating an example requires us to run something else to make that effective. A better approach would be:

1. Projects live as a module inside bob.extension
2. Documentation building generate the tarballs when it builds

This way we don't have a 2-step dev process.

These tarballs live inside the package, and they are inside GitLab. When building the tarballs in another process, such as during documentation generation, we need to upload them somewhere else, and change the documentation (see link above) accordingly. Also, we need to change the test_extensions test cases to work with those packages.

If the conda environment works better with this approach, I am fine with that. Otherwise, I don't see any need for an action. I agree that updating the tarballs requires a two-step process, but given that we don't update these packages often, I would be able to live with that, especially since there is a simple script that you can call, which does the update for you.

The action that is required is that these projects cannot depend on bob.blitz. It simply does not work inside the conda packages.

In the mid-term future, we'll deprecate the current build strategy and only maintain the conda-package builds. This allow the conda-recipes to be maintained individually by each maintainer and kept inside the package itself. It will also give us a better release procedure and offload work from a few that need to maintain the conda builds. When we reach this, we'll need to stop testing these extensions if it continues to have a circular dependence as it is today.

So we can continue to test the extension building, even if we're inside a conda package test procedure, we need to remove the circular dependence and make sure all required material to test a package is shipped with the package itself (as much as possible).

So, we are finally going back to the monolithic bob package, where we (more precisely I) spent so much time in developing better solutions to split this package up into smaller packages? Why do we still have these small packages then, if we always install them altogether in the conda environment?

Also, why do we still have exceptions to these, e.g., all the database packages, and bob.bio are installed via pip on top of the conda environment? Why don't we install all packages via conda or via pip?

Anyways, you do what you think is the best to do.

There is no monolithic builds! I guess you misunderstood that - we're just moving the conda packaging to each individual package. To avoid double-testing, we'll only use conda for testing.

For the pip vs conda business - it is an interesting proposal. We'll have a clearer picture when we start doing this work towards the end of the year.

Why don't we install all packages via conda or via pip?

We want to move all packages to conda based ones. This is tracked here: bob.admin#35 (closed) This is a major task and requires a lot of effort. Any help is appreciated.

added bug Important labels

Now that you have more experience with conda, does this issue still apply or can we close this?

Unfortunately, this continues to be an issue. There should be no circular dependencies anywhere (even as short as this).

bob.extension >> grep bob.blitz -rl .
./bob/extension/scripts/dependency_graph.py
./bob/extension/examples/bob.example.extension/bob/example/extension/__init__.py
./bob/extension/examples/bob.example.extension/bob/example/extension/main.cpp
./bob/extension/examples/bob.example.extension/bob/example/extension/script/reverse.py
./bob/extension/examples/bob.example.extension/bob/example/extension/script/version.py
./bob/extension/examples/bob.example.extension/bob/example/extension/version.cpp
./bob/extension/examples/bob.example.extension/requirements.txt
./bob/extension/examples/bob.example.extension/setup.py
./bob/extension/examples/bob.example.library/bob/example/library/__init__.py
./bob/extension/examples/bob.example.library/bob/example/library/main.cpp
./bob/extension/examples/bob.example.library/bob/example/library/script/reverse.py
./bob/extension/examples/bob.example.library/bob/example/library/script/version.py
./bob/extension/examples/bob.example.library/bob/example/library/version.cpp
./bob/extension/examples/bob.example.library/requirements.txt
./bob/extension/examples/bob.example.library/setup.py
./bob/extension/examples/bob.example.project/bob/example/project/script/version.py
./bob/extension/examples/bob.example.project/requirements.txt
./doc/cpp_api.rst
./doc/cplusplus_library.rst
./doc/links.rst
./doc/extra-intersphinx.txt
./doc/cplusplus_modules.rst
./doc/pip.rst
./doc/pure_python.rst

@andre.anjos I am not sure, what the output of grep bob.blitz -rl . should tell me. I know what is contained in the package, but I don't know what is your problem with that.

OK. The only place where we have a circular dependency is in the test cases, specifically in https://gitlab.idiap.ch/bob/bob.extension/blob/master/bob/extension/test_extensions.py These tests are intended to test to build new packages on top of bob.extension using buildout. In the test I tried to make sure that other bob packages (bob.blitz in this case, see: https://gitlab.idiap.ch/bob/bob.extension/blob/master/bob/extension/examples/bob.example.library/requirements.txt) can be successfully compiled and linked with the current bob.extension module. I think these tests are very valid since they test functionality of bob.extension.

Now, there seems to be an issue to test buildout in the conda environment (which I still don't understand, but I guess you know more details than me). Maybe we can define a condition (e.g., access to buildout) to skip the tests and remove the test cases in the conda environment, while we still should keep the test (and the dependency) when installed with pip. Would that be a possibility?

This issue is blocking !32 . please see https://gitlab.idiap.ch/bob/bob.extension/-/jobs/91000

changed milestone to %Conda-based CI

I have disabled the tests for this in master now.

The solution to be taken here is to move the related tests to the closest package using them: bob/bob.blitz.

assigned to @pkorshunov

mentioned in commit bob.blitz@59640c0b

mentioned in commit e8a542f6

mentioned in merge request !105 (merged)

mentioned in merge request bob.blitz!12 (merged)

closed via merge request !105 (merged)

mentioned in commit afd18474

closed via commit e8a542f6

mentioned in commit bob.blitz@8365cffd