Alternatively, it would be good to specify both some requirements and auto-detect š¤
Exactly, it should have auto-detected the package.
Hi UnevenDolphin73 , when you say pipeline itself you mean the controller? The controller is only in charge of handling the components. Lets say you have a pipeline with many parts. If you have a global environment then it will force a lot of redundant installations through the pipeline. What is your use case?
I have no idea whatās the difference, but it does not log the internal repository š If I knew why, I would be able to solve it myself⦠hehe
Then the type hints are not removed from helper and the code immediately crashes when being run
Oh yes I see your point, that does make sense (btw removing the type hints will solve the issue)
regardless let me make sure this is solved
Hey @<1523701205467926528:profile|AgitatedDove14> , thanks for the reply!
We would like to avoid dockerizing all our repositories. And for the time being we have not used the decorators, but we can do that too.
The pipeline is instead built dynamically at the moment.
The issue is that the components do not have their dependency. For example:
def step_one(...):
from internal.repo import private
# do stuff
When step_one is added as a component to the pipeline, it does not include the āinternal.repoā as a package dependency, so it crashes.
How or why is this the issue? I great something is getting lost in translation :D
On the local machine, we have all the packages needed. The code gets sent for remote execution, and all the local packages are frozen correctly with pip.
The pipeline controller task is then generated and executed remotely, and it has all the relevant packages.
Each component it launches, however, is missing the internal packages available earlier :(
is this repo installed on the machine creating the pipeline ?
You can also manually add it here `packages={"link_to_internal_python_package",]
None
If you use this one for example, will the component have pandas as part of the requirement
None
def step_two(...):
import pandas as pd
# do stuff
If so (and it should), what's the difference, where is "internal.repo " different from pandas ?
PricklyRaven28 That would be my fallback, it would make development much slower (having to build containers with every small change)
How or why is this the issue?
The main issue is a missing requirement on the Task component, and this is why it is failing.
You can however manually specify package (and I'm assuming this will solve the issue), but it should have autodetected, no?
We have an internal mono-repo and some of the packages are required - theyāre all available correctly for the controller, only some are required for the individual tasks, but the āmagicā doesnāt happen š
That is, the controller does not identify them as a requirement, so theyāre not installed in the tasks environment.
Itās just that for the packages argument, ClearML says:
If not provided, packages are automatically added based on the imports used inside the wrapped function.
So⦠š¤
I think this is the main issue, is this reproducible ? How can we test that?
⦠And itās failing on typing hints for functions passed in pipe.add_function_step(ā¦, helper_function=[ā¦]) ⦠I guess those arenāt being removed like the wrapped function step?
We also wanted this, we preferred to create a docker image with all we need, and let the pipeline steps use that docker image
That way you donāt rely on clearml capturing the local env, and you can control what exists in the env
So a missing bit of information that I see I forgot to mention, is that we named our packages as foo-mod in pyproject.toml . That hyphen then getās rewritten as foo_mod.x.y.z-distinfo .
foo-mod @ git+
It is. In what format should I specify it? Would this enforce that package on various components? Would it then no longer capture import statements?
And is this repo installed on the pipeline creating machine ?
Basically I'm asking how come it did not automatically detect it?
Weād be happy if ClearML captures that (since it uses e.g. pip, then we have the git + commit hash for reproducibility), as it claims it would š
Any thoughts CostlyOstrich36 ?
Still; anyone? š„¹ @<1523701070390366208:profile|CostlyOstrich36> @<1523701205467926528:profile|AgitatedDove14>
We can change the project nameās of course, if thereās a suggestion/guide that will make them see past the namespaceā¦
Using the PipelineController with add_function_step
Well the individual tasks do not seem to have the expected environment.
There's no decorator, just e.g.
def helper(foo: Optional[Any] = None):
return foo
def step_one(...):
# stuff
Then the type hints are not removed from helper and the code immediately crashes when being run
There's code that strips the type hints from the component function, just think it should be applied to the helper functions too :)
not sure about this, we really like being in control of reproducibility and not depend on the invoking machine⦠maybe thatās not what you intend