Python3, pip, and venv

One of the lines in The Zen of Python says “There should be one — and preferably only one — obvious way to do it”. But there are more than 10 different ways to set up virtual environments in Python, some of them no longer applicable for Python 3. This Red Hat Developer blog explains the best practices for working with pip and venv:

From the TL;DR section:

$ mkdir ~/pydev
$ cd ~/pydev
$ python3 -m venv py36-venv
$ source py36-venv/bin/activate
(py36-venv) $ python3 -m pip install ...some modules...

Note that venv is preferred to virtualenv in Python 3 (as explained here). Also, virtual environments are preferred to pip --user (as explained here).

CMSSW Phase-2 geometry numbering

The various Phase-2 geometry descriptions are documented in Configuration/Geometry/

Available RelVal workflows for all geometries can be found by doing -w upgrade -n. (The possible -w arguments are listed in Configuration/PyReleaseValidation/python/).

Related to this, the various pileup scenarios are detailed in Configuration/StandardSequences/python/ The ‘auto’ conditions are detailed in Configuration/AlCa/python/ The ‘era’ parameters are detailed in Configuration/StandardSequences/python/

For Phase-2 L1T Upgrade TDR studies, I used geometry Extended2023D41, era Phase2C8_timing_layer_bar, beamspot HLLHC14TeV, conditions auto:phase2_realistic, pileup AVE_200_BX_25ns.

Update GitHub forked repository

When you fork a repository on GitHub, you get a copy of the upstream repository. But the forked repository doesn’t receive future updates from the upstream repository. You would have to do that manually. GitHub has some useful help pages:

Suppose you start by forking a repo, and git clone from the forked repo (as opposed to the upstream repo). If you do git remote -v in your working area, you should see something like:

git remote -v
#  origin (fetch)
#  origin (push)

Now, you want to add the upstream as a new remote:

git remote add upstream

To verify that you have added it successfully, you can do git remote -v again.

Suppose the branch you want to update is the ‘master’ branch. In your working area, the master branch is pointing to the fork remote, not to the upstream remote. This can be confusing. To avoid the confusion, I suggest to rename the existing master branch into something else:

git branch -m YOUR_BRANCH

To verify that you have renamed it successfully, you can do git branch.

Push this branch to the fork remote:

git push -u origin YOUR_BRANCH

Then, check out the master branch from the upstream remote. From now on, the master branch is pointing to the upstream remote:

git fetch upstream
git checkout -t upstream/master

Push this recreated master branch to your fork remote, overwriting what is currently there:

git push --force origin master

In the future, to receive updates from the upstream master branch, and apply those updates to your local repo and your fork repo:

# Pull from upstream, but push to origin (a.k.a. fork)
git checkout master
git pull
git push origin master