M-Labs/thermostat
9
0
Fork 5
Code Issues 9 Pull Requests 5 Releases Wiki Activity

flake: Dev convenience wrappers & environment #145

Open
atse wants to merge 2 commits from atse/thermostat:flake-dev-conveniences into master
pull from: atse/thermostat:flake-dev-conveniences
merge into: M-Labs:master
Conversation 4 Commits 2 Files Changed 1 +4
atse commented 2024-11-04 16:43:40 +08:00
Contributor
Copy Link

Makes PyThermostat contents more exposed and easier to bring up in the devShell.

For instance, after running nix develop, one can simply run:

thermostat_plot

in the shell to run pythermostat/pythermostat/plot.py, with its source frozen at the point when the shell is entered.

For running the scripts with the current source on disk, run

python -m pythermostat.plot

This is more useful for development.

Also, in a Python shell,

>>> from pythermostat.client import Client
>>> thermostat = Client()

Then one can use Python to interactively interface with the Thermostat.

Makes PyThermostat contents more exposed and easier to bring up in the devShell. For instance, after running `nix develop`, one can simply run: ```sh thermostat_plot ``` in the shell to run `pythermostat/pythermostat/plot.py`, with its source frozen at the point when the shell is entered. For running the scripts with the current source on disk, run ```sh python -m pythermostat.plot ``` This is more useful for development. Also, in a Python shell, ```python >>> from pythermostat.client import Client >>> thermostat = Client() ``` Then one can use Python to interactively interface with the Thermostat.
atse added 2 commits 2024-11-04 16:43:40 +08:00 
For easier testing of pytec client code in the shell.
Makes it possible to directly run `plot` and `autotune` in the shell.
esavkin commented 2024-11-04 16:51:08 +08:00
Owner
Copy Link

Wouldn't this plot command be more applicable for the customers, rather than devs? I thought in dev environment it is faster to directly edit and call the python files, rather than building a nix develop on each change.
I think this PR is fine, just for the future shouldn't we export it for the customers?

Wouldn't this `plot` command be more applicable for the customers, rather than devs? I thought in dev environment it is faster to directly edit and call the python files, rather than building a `nix develop` on each change. I think this PR is fine, just for the future shouldn't we export it for the customers?
atse commented 2024-11-04 17:16:28 +08:00
Author
Contributor
Copy Link

rather than building a nix develop on each change

No need for that though, since the wrapper script simply calls Python to run the wrapped modules pytec/plot.py or pytec/autotune.py, so changes in those files would immediately show on run. This is really just a glorified alias.

As for the customers, what is the best way to export it? Do we make another devShell or a bash script? Or make it nix run-able?

> rather than building a `nix develop` on each change No need for that though, since the wrapper script simply calls Python to run the wrapped modules `pytec/plot.py` or `pytec/autotune.py`, so changes in those files would immediately show on run. This is really just a glorified alias. As for the customers, what is the best way to export it? Do we make another devShell or a bash script? Or make it [`nix run`-able](https://nix.dev/manual/nix/2.18/command-ref/new-cli/nix3-run.html?highlight=apps#apps)?
atse force-pushed flake-dev-conveniences from c8b6bf01d1 to 5bea19be36 2024-11-04 17:16:52 +08:00 Compare
esavkin commented 2024-11-04 17:45:05 +08:00
Owner
Copy Link

so changes in those files would immediately show on run

But is it so? As far as I remember all files nix references are stored in nix store, meaning it was copied when nix develop is called.

> so changes in those files would immediately show on run But is it so? As far as I remember all files nix references are stored in nix store, meaning it was copied when `nix develop` is called.
atse commented 2024-11-04 18:10:26 +08:00
Author
Contributor
Copy Link

Ahh, that would be the case if PYTHONPATH was exported as ${self}/pytec:$PYTHONPATH in the devShell's shellHook. Here, the ${self} is `pwd` instead to make it refer to the repo's working directory.

Ahh, that would be the case if `PYTHONPATH` was exported as `${self}/pytec:$PYTHONPATH` in the devShell's shellHook. Here, the `${self}` is `` `pwd` `` instead to make it refer to the repo's working directory.
sb10q reviewed 2024-11-04 18:36:10 +08:00
flake.nix Outdated
@ -52,0 +60,4 @@
echo "exec python3 -m $progname \"\$@\"" >> $outname
chmod 755 $outname
fi
done
sb10q commented 2024-11-04 18:36:10 +08:00
Owner
Copy Link

Why not package them normally e.g. with Python setup entry points?

Why not package them normally e.g. with Python setup entry points?
atse commented 2024-11-11 15:51:10 +08:00
Author
Contributor
Copy Link

Ah right! That would be the solution for the customers' end. However I think we'll have to use these wrappers for development, otherwise local changes wouldn't be reflected in the commands in $PATH.

Ah right! That would be the solution for the customers' end. However I think we'll have to use these wrappers for development, otherwise local changes wouldn't be reflected in the commands in `$PATH`.
atse commented 2024-11-11 17:17:10 +08:00
Author
Contributor
Copy Link

I've added the setup entry points in #149.

I've added the setup entry points in #149.
atse marked this conversation as resolved
sb10q reviewed 2024-11-04 18:37:07 +08:00
flake.nix Outdated
@ -68,2 +82,4 @@
numpy matplotlib
]);
shellHook = ''
export PYTHONPATH=`pwd`/pytec:$PYTHONPATH
sb10q commented 2024-11-04 18:37:07 +08:00
Owner
Copy Link

In ARTIQ this is:

export PYTHONPATH=`git rev-parse --show-toplevel`:$PYTHONPATH

The dev shell can be entered from a subfolder, and your version would break.

In ARTIQ this is: ``` export PYTHONPATH=`git rev-parse --show-toplevel`:$PYTHONPATH ``` The dev shell can be entered from a subfolder, and your version would break.
atse commented 2024-11-11 12:24:28 +08:00
Author
Contributor
Copy Link

Hmm, but this would be Git-specific is it not? How about something like:

flake_root=$(pwd)

while [ "$flake_root" != / ]; do
  if [ -e "$flake_root/flake.nix" ]; then
    export PYTHONPATH="$flake_root/pytec":$PYTHONPATH
    break
  fi
  flake_root=$(dirname "$flake_root")
done
Hmm, but this would be Git-specific is it not? How about something like: ```bash flake_root=$(pwd) while [ "$flake_root" != / ]; do if [ -e "$flake_root/flake.nix" ]; then export PYTHONPATH="$flake_root/pytec":$PYTHONPATH break fi flake_root=$(dirname "$flake_root") done ```
sb10q commented 2024-11-16 13:08:09 +08:00
Owner
Copy Link

Looks a bit complicated and I don't see a situation where a developer would enter the shell without using Git.

Looks a bit complicated and I don't see a situation where a developer would enter the shell without using Git.
👍 1
atse commented 2024-11-18 11:18:59 +08:00
Author
Contributor
Copy Link

pwd -> git rev-parse --show-toplevel in the force-push to d38864740b.

`pwd` -> `git rev-parse --show-toplevel` in the force-push to d38864740b.
atse marked this conversation as resolved
atse force-pushed flake-dev-conveniences from 5bea19be36 to d38864740b 2024-11-18 11:17:42 +08:00 Compare
atse force-pushed flake-dev-conveniences from d38864740b to d815a9ae55 2024-11-18 18:03:50 +08:00 Compare
atse force-pushed flake-dev-conveniences from d815a9ae55 to 16c78c5784 2024-11-25 10:29:33 +08:00 Compare
atse force-pushed flake-dev-conveniences from 16c78c5784 to 1a3c831a06 2024-11-25 11:12:42 +08:00 Compare
sb10q reviewed 2024-11-25 11:27:17 +08:00
flake.nix Outdated
@ -72,0 +80,4 @@
echo "exec python -m $progname \"\$@\"" >> $outname
chmod 755 $outname
fi
done
sb10q commented 2024-11-25 11:27:17 +08:00
Owner
Copy Link

I think this isn't needed if you have the setup.py entry points?

I think this isn't needed if you have the setup.py entry points?
atse commented 2024-11-25 11:57:06 +08:00
Author
Contributor
Copy Link

But don't the entry points require pip install-ing the package for them to be in the PATH? In a development shell we would ideally want them to be in PATH already without any installing.

But don't the entry points require `pip install`-ing the package for them to be in the `PATH`? In a development shell we would ideally want them to be in `PATH` already without any installing.
sb10q commented 2024-11-25 11:59:40 +08:00
Owner
Copy Link

No, just create a Nix Python package the regular way (see artiq or sipyco) and put that into the shell inputs. No pip.

But note that artiq follows a different approach for the development shells where you'd run the frontend tools as python -m artiq.frontend.xxx - because when developing you typically want the current source on the disk, not what the source was when the shell was entered.

No, just create a Nix Python package the regular way (see artiq or sipyco) and put that into the shell inputs. No pip. But note that artiq follows a different approach for the development shells where you'd run the frontend tools as ``python -m artiq.frontend.xxx`` - because when developing you typically want the current source on the disk, not what the source was when the shell was entered.
👍 1
atse commented 2024-11-25 13:29:10 +08:00
Author
Contributor
Copy Link

Done in force-push to f21f9257a7.

Done in force-push to f21f9257a7.
atse marked this conversation as resolved
atse force-pushed flake-dev-conveniences from 1a3c831a06 to f21f9257a7 2024-11-25 12:56:14 +08:00 Compare
This pull request can be merged automatically.
This branch is out-of-date with the base branch
You are not authorized to merge this pull request.
View command line instructions.

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u flake-dev-conveniences:atse-flake-dev-conveniences
git checkout atse-flake-dev-conveniences
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No Label
Milestone
Clear milestone
No items
No Milestone
Assignees
Clear assignees
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: M-Labs/thermostat#145
No description provided.
Delete Branch "atse/thermostat:flake-dev-conveniences"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?