substra / substra-tools Goto Github PK

This is an alternative to the run-local command.

Example of python sripts to test an algo/opener:

import tensorflow as tf
import algo.algo as algo
import dataset.opener as opener
o = opener.Opener()
X = o.get_X(["dataset/train/train1"])
y = o.get_y(["dataset/train/train1"])
a = algo.ModelComp(local_folder='./sandbox/local/')
pred, model = a.train(X, y, None, None, 0)

This would avoid telling our users to use an hardcoded path.

We could use a generator to load them when needed, it will be needed to avoid running out of memory.

To be updated:

• traintuple.models
• aggregatetuple.models

In function.py we have 2 different execute functions, and it's really difficult when calling for instance function.execute([to know which one is used, we have to track the function object type.
I propose to rename one of them, like execute_function for the one in wrapper or execute_cli for the one running the cli

Don't make it backward compatible: it will complexify the code.

We could define a few serializers in substra-tools to avoid users writing their own.

We could create numpy; json and pickle serializers to start with.

Proposition of API:

class MyAglo(tools.Algo):
    model_serializer = tools.serializers.NUMPY

    def train():
        ...

Note: we should not break the existing API; we should still be able to define manually the load and save methods.

As substratools is now open source we don't need to build and provide docker images.
End users could directly install subtratools through pip and don't need to create a Dockerfile inheriting from substratools.

It will allow them to choose the base image.

One of the issue is that currently substra-backend relies on the fact that the working directory inside the container is /sandbox (hardcoded value).

That's the reason why to get rid of the substratools, we must first ensure that:

• all paths can be defined in substratools command line interfaces
• substra-backend is passing the expected paths through the command line interface

We will then be able to update all the Dockerfile and stop inheriting from substratools images.

EDIT:

⚠️ The substra-tools image is really useful for a quick development loop: update substratools code, rebuild the image and launch the tests locally. If substratools is installed from pypi in the end to end tests, we won't be able to test new substratools changes. So I think, we should continue to publish substratools docker images to the docker registry and use them for the end to end tests.

One of the issue is that currently substra-backend relies on the fact that the working directory inside the container is /sandbox (hardcoded value).

Tasks to be done:

• all paths can be defined in substratools command line interfaces (no more hardcoded paths)
• substra-backend is passing the expected paths through the command line interface

Substratools should follow the same rules as the substra package: release on pypi when creating git tags.

The description of the package substratools is not fetched from the setup.py file whereas it is working for the substra package. On both projects, the uploader had a travis token added before.
Any idea why this is happening?
It would be great to have description='Python tools to submit algo on the Substra platform' displayed to the world!

This would allow us to check that the version has been correctly incremented.