Skip to content

Refactor / Remove the Task Templating Mechanism #360

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
popescu-v opened this issue Feb 13, 2025 · 3 comments
Open

Refactor / Remove the Task Templating Mechanism #360

popescu-v opened this issue Feb 13, 2025 · 3 comments
Assignees
Labels
Priority/0-High To do now Size/Weeks Needs some weeks (big) Status/ReadyForDev The issue is ready to be developed or to be investigated deeply
Milestone

Comments

@popescu-v
Copy link
Collaborator

popescu-v commented Feb 13, 2025

Description

Currently, the task templating mechanism allows khiops-python to instantiate Khiops scenarios based on input parameters specified through the khiops.core API.

In Khiops 11 there is a JSON-based templating mechanism which does essentially the same thing

Questions/Ideas

  • The goal of this issue is to:

    • reduce the templating mechanism to providing a JSON file storing the scenario attributes and pairing it with a scenario template that Khiops Core can consume
    • outsource to Khiops core the template instantiation into scenarios (with all associated error checking).
  • We need to see whether and how the scenario templates can be mutualized / centralized between Khiops Core and Khiops Python.

  • We also need to see whether the Core API function argument preprocessing can be simplified (passage from None to different default values, etc).

@popescu-v popescu-v added Priority/2-Low To do after P1 Size/Weeks Needs some weeks (big) Status/Draft The issue is still not well defined labels Feb 13, 2025
@popescu-v popescu-v added this to the 11.0.0.0 milestone Feb 13, 2025
@popescu-v
Copy link
Collaborator Author

popescu-v commented Feb 17, 2025

Confirm that on the Khiops side the types of the fields are checked.
If not, use the Python type hints on the API side (the types module).

@popescu-v popescu-v modified the milestones: 11.0.0.0, 11.0.1.0 Feb 20, 2025
@popescu-v
Copy link
Collaborator Author

popescu-v commented Mar 3, 2025

We can start by unregistring each task one by one (replace it with a bare-bones Python task dictionary).

@popescu-v popescu-v added Priority/0-High To do now Status/ReadyForDev The issue is ready to be developed or to be investigated deeply and removed Status/Draft The issue is still not well defined Priority/2-Low To do after P1 labels Mar 6, 2025
@popescu-v popescu-v mentioned this issue Mar 13, 2025
6 tasks
@marcboulle
Copy link

Tenter de spécifier partout ou c’est possible une valeur par défaut, plutôt que None

A priori, c’est possible partout, sauf pour ‘max_cores’ et ‘memory_limit_mb’

Pour le cas ‘header_line’ et ’field_separator’, la documentation suivante me semble plus intuitive que la version actuelle :

detect_format : bool, default True
If True detects automatically whether the data table file has a header and its field separator. If it is set to False , header_line and field_separator are used
header_line : bool, default True
If True it uses the first line of the data as column names. Ignored if detect_format is True.
field_separator : str, default “\t”
A field separator character “” has the same effect as “\t”. Ignored if detect_format is True.
Avec la signature suivante dans les fonctions impactée
detect_format=True, header_line=True, field_separator=”\t”

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Priority/0-High To do now Size/Weeks Needs some weeks (big) Status/ReadyForDev The issue is ready to be developed or to be investigated deeply
Projects
None yet
Development

No branches or pull requests

3 participants