I have a question regarding updates to PyHamilton. Is there a pip command to update to the newest version, or will a re-install be the best option?
I’m also wondering, since I’ve added random source-code bits here and there (like certain deck resources, currently working on expanding the API to NTRs, etc) is it worthwhile me getting involved as a contributor through Git as you detailed in your Guide to Open Source post? Or are these contributions too small?
I have a question regarding updates to PyHamilton. Is there a pip command to update to the newest version, or will a re-install be the best option?
pip install pyhamilton --upgrade will work here
I’m also wondering, since I’ve added random source-code bits here and there (like certain deck resources, currently working on expanding the API to NTRs, etc) is it worthwhile me getting involved as a contributor through Git as you detailed in your Guide to Open Source post? Or are these contributions too small?
Not too small! I don’t think we will accept a PR with the NTR library integrated into Venus though, because I think that is better off done with pure Python. If you have a way of doing it in Python (or want me to do it), I’ll pull that.
Hi Stefan
I am beginning my preparations for contributing to PyHamilton through GitHub. I have forked the repository and made a local clone in its own Python environment. I am however having trouble running this cloned version of PyHamilton. Naturally, the local files now simply mirror the GitHub repo, which does not contain pyhamilton-configure nor pyhamilton-new-project. I got around this by simply copy/pasting those scripts into the Scripts folder of my clone environment. Is that an alright way to get around that issue? It worked and I was able to execute both without any issues.
The big problem I’m having now is the fact that the interpreter can’t find pyhmilton when trying to execute robot_method.py after making a new project with pyhamilton-new-project. The exact error is
ImportError: cannot import name 'HamiltonInterface' from 'pyhamilton' (unknown location)
I suspect this may have something to do with my file structures. I cloned the repo (with a unique name) to the same location that pyhamilton would otherwise have been installed in, namely ...Lib\site-packages\pyhamilton-deckresource-extension. Opening that folder then reveals the repo as cloned from GitHub, which as you know contains a pyhamilton folder in which all the .py files are stored.
I think the issue could be:
Your help would be greatly appreciated!
JF
Edit: I also wonder if, since I am not using pip to install the files, I might be missing some required modeules.
Hi,
Don’t git clone into your site-packages or system path. You should definitely delete the repo you cloned there. Here is how you make edits to a repo that will be pip installable.
pip install -e <path>Now, the repo will be installed and automatically updated with whatever changes you make to the local project. You dont have to reinstall every time. This is the best way to do development work on any Python package.
Also, the pyhamilton-configure etc scripts are accessed as console entrypoints in setup.py. Check those out. They only get installed with an actual pip installation, which is why they didnt show up here.
The reason pyhamilton isnt showing up is because you changed the directory name I think, but that will alk be fixed with a pip install.
Hi Stefan, thanks for the above. Just a couple of simple questions, sorry for the inexperience!
add/commit/push commands in Bash?Many thanks!
pip install -e is a command to install a local package as editable. Normally, when you use pip install (without -e), the files are copied into the {pythondir}/site-packages directory so they are directly callable from a python script which imports that package. In this case, any changes to the original files will not be transferred to the site-packages files, if you wanted that to happen you would pip install again.
When using -e, you are actually creating a symlink, in {site-packages} to the files you are installing, so any changes to those will automatically be reflected in the imported module.It is useful for developing a python package as you don’t have to keep pip installing. So for example, if you clone the repo to ~/Developer/pyHamilton, and run pip install -e ., symlinks in {pythondir}/site-packages would link to the files in ~/Developer/pyHamliton. You then make changes to those files (~/Developer/pyHamilton), then commit and push as a pull request to the github remote. That part isn’t done automatically - that is at your discretion. Hope that helps!
I am busy writing wrapper functions to handle the HHS commands that exist within STAR_OEM_NoFan. I have a question regarding whether the functions should be written in utils.py or in a separate file such as HHS_command_wrappers.py. The reason I ask is because I notice that the pH module has its own .py file for the wrappers.
Another question I have is regarding importing the functions into a script. When I have the functions in their own HHS_command_wrappers.py file then I cannot simply write from pyhamilton import (...), but I notice that you can import the pH commands in that manner. Why?
Stefan, regarding submitting these HHS wrapper additions to your repo. Would you prefer a pull request opened early while development is ongoing? Or would you prefer it when I think it’s complete?
Important note to contributors: If you are making changes to a fork, I strongly recommend pulling updates from the original dgretton\pyhamilton repo relatively frequently. This ensures that you are working with an up-to-date copy of the original repo and that we resolve any conflicts between the two repos as soon as possible.
Here are some resources that will help with this:
Another question I have is regarding importing the functions into a script. When I have the functions in their own HHS_command_wrappers.py file then I cannot simply write from pyhamilton import (…), but I notice that you can import the pH commands in that manner. Why?
Check out __init__.py to see how we move functions from a script into the package namespace:
from .interface import *
from .deckresource import *
from .oemerr import *
from .pH_command_wrappers import *
from .utils import *
Basically, whatever functions, variables, classes etc. exist in the __init__.py namespace will be available in the package namespace.
I have a question regarding whether the functions should be written in
utils.pyor in a separate file such asHHS_command_wrappers.py. The reason I ask is because I notice that the pH module has its own .py file for the wrappers.
Yes, I think having a separate wrappers file for each piece of equipment will be appropriate from now on. It’s much better than having the utils.py folder be a catch-all which will inevitably lead to clutter.
Stefan, regarding submitting these HHS wrapper additions to your repo. Would you prefer a pull request opened early while development is ongoing? Or would you prefer it when I think it’s complete?
If you have code that works, I can pull that even if you still have more to add. That’s up to you.
Thanks for your interest in contributing! I’m looking forward to adding more of your code to the repo.
Hi Stefan
I am well on my way with the HHS wrapper commands. I am however stumbling when it comes to the return data, specifically the return fields. I have looked through the pH module wrapper commands but I cannot make much sense out of when to omit anything relating to the return fields, when to include something like:
return_fields = ['step-return2', 'step-return3', 'step-return4', 'step-return5']
and what the numbering of the step returns relates to. Could you point me in the right direction here Stefan? My error message is in the code below.
Edit: I seem to have managed to get something working. Not entirely sure what I did, because I think all I did was update my fork to match the official pyhamilton repo. Regardless, my questions above are still mostly valid as I’m still not certain as to what the return_fields represent!
Another question I have is regarding the STAR_OEM_Test.lay file. It always incurs indirect changes when I test changes to the source code. Should I include STAR_OEM_Test.lay with my commits, or should I omit it?
One final question on the general topic of the STAR_OEM files… Why are there so many of them and what is their purpose? We have STAR_OEM, STAR_OEM_Toolkit, STAR_OEM_Test, STAR_OEM_NoFan, STAR_OEM_wFan 
I’m interested to know how they all tie together!
Hi,
Thanks as always for the insightful questions.
Edit: I seem to have managed to get something working. Not entirely sure what I did, because I think all I did was update my fork to match the official pyhamilton repo. Regardless, my questions above are still mostly valid as I’m still not certain as to what the return_fields represent!
Funny enough I actually just fixed this, which is why it started to work for you. This is an excellent demonstration of good open-source practices!
To your question: Some of our wrappers include a field return_data such that HamiltonInterface.wait_on_response(..., return_data=['step-return2']). This means that instead of performing normal error checking (or ignoring) a field in the JSON response string from the Venus method, we actually return the data from the wrapper function. This is used if we have a sensor integrated into PyHamilton that is called from Venus.
If you don’t return sensor data or something similar that you want to process in Python, there’s no need to have return_data be anything but the default value which is None.
Another question I have is regarding the STAR_OEM_Test.lay file. It always incurs indirect changes when I test changes to the source code. Should I include STAR_OEM_Test.lay with my commits, or should I omit it?
That’s a great point that has annoyed me for some time as well. I think we can add the .lay to a .gitignore file and avoid shipping it with the core library. It’s only been a headache for users.
One final question on the general topic of the
STAR_OEMfiles… Why are there so many of them and what is their purpose? We haveSTAR_OEM,STAR_OEM_Toolkit,STAR_OEM_Test,STAR_OEM_NoFan,STAR_OEM_wFan
So, STAR_OEM_noFan.hsl is of course the PyHamilton universal method. ...Toolkit is a sub-method library that we use to hold wrapper functions that we import into the universal method. ...wFan.hsl is a slightly out of date universal method that contains functions for interacting with a HEPA fan.
My lab (Sculpting Evolution, which invented PyHamilton), uses the HEPA fans for our methods, but you can’t even open a method containing a fan function if your machine/ software is not configured with a fan. I don’t know how to change this, and no other piece of equipment is like this. So we have two universal methods. noFan is the default that almost every PyHamilton user in the world uses, and wFan is I think only used by Sculpting Evolution.
There’s a bunch of other methods in VENUS_Method that are not part of this explanation. I think some of those could be removed without consequence, but I don’t actually know, and I haven’t felt compelled to try.
Hi Stefan
I am beginning to work on incorporating the Inheco ODTC into PyHamilton. I have two sets of files that need to be included to operate it. The first is the ODTC library itself, and then the second is a “driver” .smt file that will require an install. I assume that the library should go into the only library folder present in the repo, correct? The only other question I have is regarding the .smt file that requires an install. Which bin folder should that go into? From what I can tell it is the same bin folder that the pH installer is in, but I just wanted to make sure!
Hi, can you send me the .smt file so I can see what is in this?
