Overview
We typically run the version of ipython/jupyter from APS share in a conda enviroment. A conda environments is a directory which contains a specific collection on conda packages and python modules. Multiple conda environments can be can be installed, each with its own set of packages.
iexcode, iexplot, orangebook are python packages. They need to be installed in the environment that you are using. If you modify the code you will need to reinstall it.
Workflow for User account (29iduser)
The code here should not be used for development, this should be a stable working version, only debug what is not working.
working directory
- /home/29IDUSER/Documents/User_Macros/Macros_29id/
local git repo
- /home/29IDUSER/Documents/python_workspace
Activating the python environment
There is a aliases to activate the current environment for the command line, ipython and jupyter. If we change which version of jupyter or ipython or environment these aliases need to be updated
- activate_29id: activate the current preferred environment; required for installing new packages or reinstalling edited code
- ipython_29id: activate the environment, navigate the User_Macro directory, starts ipython
- jupyter_29id: navigate the User_Macro directory, starts jupyter
Debugging the working version of the code
- navigate to the local repo (see above)
- git status (to see what the current status of the code local vs remote repos and decide if you need to commit)
- git pull (to get the latest version of the code from the remote repo)
- make your changes with your favorite editor
- git commit .
- git pus
Workflow for code development
Login as yourself (beamline or personal computer):
- set up VSCode or your favorite editor/IDE
- set up conda env / ipython config / startup etc
- clone repo to a local folder
Sync and create new branch
1. git checkout main # switch and/or make sure you are on the “main” branch
2. git fetch # check for changes of main repository
3. git pull # update your “main” branch to sync to remote repository
4. git checkout -b branchX # create new branch from “main” named branchX and switch to it
Make your changes
Commit changes regularly; think atomique commits (commit files one by one vs big all-together combined commit):
1. git status # check status to see a list of the files with changes
2. git add oneFile # stage file for commit
3. git commit -m 'a comment' # commit the staged file with a commit message
4. git log # check commit message; start over to step 1 for next file
or, from VSCode:
- stage file using + sign
- enter commit message
- commit file using checkmark
- use curved arrow to undo changes
When done for the day
git push # push changes to GitLab
Then, from GitLab or VSCode:
- create pull request for your branch
- JM will review the changes and merge into main as needed.
Some tips
- You can open more than one window in VSCode
- To see preview of Mardown files side by side use extension “Auto-Open Markdown preview”: type Shift+cmd+X to open the extension marketplace; look for Auto-Open Markdown preview and install
- Only click once to open file from the side bar or it will open file as many time as you clicked (can be changed in settings)
- You can quickly end up with too many files open; you can use ”open editor” to close / reorganize
- You can see the list of functions and variables for a given file in “outline”; collapse all to see only the functions
- Timeline shows commit messages for a given file
- The letter on the side of a files indicates uncommitted changes: M = modified; D = deleted; U = untracked (only for new files)
- Each commit is identified by a unique 40 characters ID called called “sha”: typically only the first 6 to 8 character are displayed; this is a good way to check where you are
- To see the list of branch: git branch
- more info: https://www.atlassian.com/git/tutorials/using-branches