Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • bob.bio.base bob.bio.base
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 15
    • Issues 15
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 1
    • Merge requests 1
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • bobbob
  • bob.bio.basebob.bio.base
  • Issues
  • #101
Closed
Open
Issue created Nov 16, 2017 by Tiago de Freitas Pereira@tiago.pereiraOwner

A programmatic way to use bob.bio.base

The verify.py script is very handy to trigger experiments. Not very recently @andre.anjos pushed a mechanism that allows us to provide configuration files as input and this made the work of preparing and triggering experiments even simpler and cleaner.

Imagine that your work consists of more than one hundred experiments with different databases (splits), preprocessors, feature extractors, etc. You can handle this complexity by spliting your configuration file in several parts and have something like this:

  $ verify.py config1.py config2.py config3.py

Although this makes the work clearner, this doesn't avoid you to call verify.py several times. A way to handle that is to have some sort of shell scripts that orchestrate these calls (or python scripts that generate the verify.py strings). Doesn't look very clean.

The script verify.py is not just a command line View for the experiment triggering; it handles the argument parsing, input validation and the experiment triggering. Today, it's not possible to detach the argument parsing from the input validation and the experiment triggering which makes impossible to programmatically trigger experiments.

We need some View-Controller design for this task.

For instance, in the View, we could wrap the content of the argument parsing in a dictionary (or use docopt that does this for free) and pass it to the Controller that will handle with the input validation and experiment triggering (it's just one way to handle this).

What would you think?

thanks

I'm willing to give a shot in this direction.

Edited Nov 16, 2017 by Tiago de Freitas Pereira
Assignee
Assign to
Time tracking