Package

[javierggt]

This PR adds all the usual stuff to turn this into a package. After this PR:

• pyproject.toml will be used to configure the package.
• index.html will be installed in the module area, and the script copies it to the output directory.
• task schedule is installed in the module area.
• Ruff workflows will run on all PRs

The conda recipe is in skare3 (sot/skare3/pull/1320).

Testing

• [x] Build and upload the package (see workflow run):

  
  from skare3_tools import github
  r = github.Repository('sot/skare3')
  r.dispatch_event(
    event_type='build-package',
    client_payload={
        "package": "obc_rate_noise_plots",
        "tag": 'package',
        "arch": True,
        "upload": True,
        "skare3_branch": "obc_rate_noise_plots",
    }
  )

• [x] Check commit hash against package version.
  • Commit: b48c829
  • Package version: 0.1.1.dev11+gb48c829
• [x] Run on HEAD:

  conda activate ska3-masters
  mamba install obc_rate_noise_plots
  obc-rate-noise-plots --root recent --outdir /proj/sot/ska/www/ASPECT_ICXC/test_review_outputs/obc_rate_noise_plots-pr5/run_1
  obc-rate-noise-plots --root longterm --duration 7.5e7 --outdir www/ASPECT_ICXC/test_review_outputs/obc_rate_noise_plots-pr5/run_1

• [x] Check output
• [x] Test task schedule:

  export SKA=/proj/sot/ska/www/ASPECT_ICXC/test_review_outputs/obc_rate_noise_plots-pr5
  mkdir -p $SKA/data/obc_rate_noise_plots/data
  ln -s /proj/sot/ska/data/* $SKA/data/
  mkdir -p $SKA/www/ASPECT/obc_rate_noise/trending
  task_schedule3.pl -package obc_rate_noise_plots

• [x] Check output

[jeanconn]

Regarding "I do not like installing the task schedule in the module area. Suggestions are welcome." I think we've just moved to installing them in the module/package area. The one thing I don't like is that we have extra task schedules floating around in share and data from other tools that are no longer being used (because the real ones are in the python package/module area).

[javierggt]

I think we've just moved to installing them in the module/package area.

Have we? When? Where? Then the path of the task schedule changes with python versions and such.

[javierggt]

The one thing I don't like is that we have extra task schedules floating around in share and data from other tools that are no longer being used

If things are properly installed in a package, when you remove a package the task schedule goes away, so there will be no stray task schedules.

Agasc is one package that has it in the share area.

[jeanconn]

"If things are properly installed in a package, when you remove a package the task schedule goes away, so there will be no stray task schedules." Yes -- there are just still old ones from ska2 and ones from packages that weren't appropriately packages.

[jeanconn]

Regarding "Have we? When? Where? Then the path of the task schedule changes with python versions and such." Yes. Tom added this "-package" option to task schedule that uses the module-determined path to run the task

https://github.com/sot/task_schedule/blob/128ffa073ce44bc6cd84bf5db144cb2218de0a60/task_schedule3.pl#L85

so all the jobs on the Ska cron jobs using the -package flag are finding the task schedule in the python package directory.

[javierggt]

It is unrelated to this PR, but agasc has two task schedules (https://github.com/sot/agasc/tree/master/task_schedules) so that -package option would not work.

[javierggt]

I'm moving the task schedule into the package then. That would not have been my choice, but since everything already uses that convention...

[jeanconn]

"It is unrelated to this PR, but agasc has two task schedules (https://github.com/sot/agasc/tree/master/task_schedules) so that -package option would not work."

You can either put the task schedule in a submodule or combine the -config option with the -package option to get around that as needed (like I just did for the acdc warm pixel plot).