https://github.com/lsst/lsstsw
loadLSST
https://github.com/lsst/lsstsw
Last synced: 11 months ago
JSON representation
loadLSST
- Host: GitHub
- URL: https://github.com/lsst/lsstsw
- Owner: lsst
- Created: 2014-08-16T07:43:19.000Z (almost 12 years ago)
- Default Branch: main
- Last Pushed: 2024-11-12T22:45:24.000Z (over 1 year ago)
- Last Synced: 2024-11-12T23:28:39.808Z (over 1 year ago)
- Language: Shell
- Homepage:
- Size: 639 KB
- Stars: 7
- Watchers: 53
- Forks: 12
- Open Issues: 3
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
LSST Distribution Server Account
================================
[](https://travis-ci.org/lsst/lsstsw)
**`repos.yaml` has been migrated to [`lsst/repos`](https://github.com/lsst/repos).**
For a guide to using `lsstsw`, see:
https://developer.lsst.io/stack/lsstsw.html
*Note: this directory is git managed.*
Structure
---------
| path | description |
| :----------|:---------------------------------------------------------------|
| miniconda | Anaconda Python distribution |
| bin | software distribution binaries (rebuild, publish) |
| build | directory where builds take place |
| distserver | EUPS distribution server directory |
| etc | configuration files live here |
| eups | local installation of EUPS |
| lfs | local installation of various packages, e.g. git (lfs stands for "Linux from Scratch") |
| lsst_build | lsst_build software tools directory (separately git managed) |
| README | the file you're reading |
| stack | the EUPS software stack into which successfully built packages are installed |
| var | contains lock files and log files |
| versiondb | version database used by lsst_build to assign +N versions (separately git managed) |
The most important directories to know about are etc (config files), stack
(the built software directory), and distserver (the distribution server
directory).
Initialization
--------------
Source bin/setup.sh to add anaconda, EUPS, git, etc. onto the path, and to
setup lsst_build tools (typically source it from ~/.bashrc).
Release workflow
----------------
Typical release workflow:
* run `rebuild`, run acceptance checks until satisfied
* git-tag the packages using mass-tag with the release tag
* rerun `rebuild` with the tags
* run `publish current`