Skip to content

Commit 3c95df3

Browse files
author
Kumara Kahatapitiya
committed
Initial commit
1 parent c47fa64 commit 3c95df3

File tree

383 files changed

+65224
-1
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

383 files changed

+65224
-1
lines changed

opensora_base

Submodule opensora_base deleted from 476b6dc
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,22 @@
1+
name: Close inactive issues
2+
on:
3+
schedule:
4+
- cron: "30 1 * * *"
5+
6+
jobs:
7+
close-issues:
8+
runs-on: ubuntu-latest
9+
permissions:
10+
issues: write
11+
pull-requests: write
12+
steps:
13+
- uses: actions/stale@v9
14+
with:
15+
days-before-issue-stale: 7
16+
days-before-issue-close: 7
17+
stale-issue-label: "stale"
18+
stale-issue-message: "This issue is stale because it has been open for 7 days with no activity."
19+
close-issue-message: "This issue was closed because it has been inactive for 7 days since being marked as stale."
20+
days-before-pr-stale: -1
21+
days-before-pr-close: -1
22+
repo-token: ${{ secrets.GITHUB_TOKEN }}
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,30 @@
1+
name: GitHub Pages
2+
3+
on:
4+
workflow_dispatch:
5+
6+
jobs:
7+
deploy:
8+
runs-on: ubuntu-22.04
9+
permissions:
10+
contents: write
11+
concurrency:
12+
group: ${{ github.workflow }}-${{ github.ref }}
13+
steps:
14+
- uses: actions/checkout@v3
15+
with:
16+
ref: gallery
17+
18+
- name: Setup Node
19+
uses: actions/setup-node@v4
20+
with:
21+
node-version: 20
22+
23+
- run: npm install
24+
- run: npm run build
25+
26+
- name: Deploy
27+
uses: peaceiris/actions-gh-pages@v3
28+
with:
29+
github_token: ${{ secrets.GITHUB_TOKEN }}
30+
publish_dir: ./build

opensora_base/.gitignore

+204
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,204 @@
1+
# Byte-compiled / optimized / DLL files
2+
__pycache__/
3+
*.py[cod]
4+
*$py.class
5+
6+
# C extensions
7+
*.so
8+
9+
# Distribution / packaging
10+
.Python
11+
build/
12+
develop-eggs/
13+
dist/
14+
downloads/
15+
eggs/
16+
.eggs/
17+
lib/
18+
lib64/
19+
parts/
20+
sdist/
21+
var/
22+
wheels/
23+
share/python-wheels/
24+
*.egg-info/
25+
.installed.cfg
26+
*.egg
27+
MANIFEST
28+
29+
# PyInstaller
30+
# Usually these files are written by a python script from a template
31+
# before PyInstaller builds the exe, so as to inject date/other infos into it.
32+
*.manifest
33+
*.spec
34+
35+
# Installer logs
36+
pip-log.txt
37+
pip-delete-this-directory.txt
38+
39+
# Unit test / coverage reports
40+
htmlcov/
41+
.tox/
42+
.nox/
43+
.coverage
44+
.coverage.*
45+
.cache
46+
nosetests.xml
47+
coverage.xml
48+
*.cover
49+
*.py,cover
50+
.hypothesis/
51+
.pytest_cache/
52+
cover/
53+
54+
# Translations
55+
*.mo
56+
*.pot
57+
58+
# Django stuff:
59+
*.log
60+
local_settings.py
61+
db.sqlite3
62+
db.sqlite3-journal
63+
64+
# Flask stuff:
65+
instance/
66+
.webassets-cache
67+
68+
# Scrapy stuff:
69+
.scrapy
70+
71+
# Sphinx documentation
72+
docs/_build/
73+
74+
# PyBuilder
75+
.pybuilder/
76+
target/
77+
78+
# Jupyter Notebook
79+
.ipynb_checkpoints
80+
81+
# IPython
82+
profile_default/
83+
ipython_config.py
84+
85+
# pyenv
86+
# For a library or package, you might want to ignore these files since the code is
87+
# intended to run in multiple environments; otherwise, check them in:
88+
# .python-version
89+
90+
# pipenv
91+
# According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
92+
# However, in case of collaboration, if having platform-specific dependencies or dependencies
93+
# having no cross-platform support, pipenv may install dependencies that don't work, or not
94+
# install all needed dependencies.
95+
#Pipfile.lock
96+
97+
# poetry
98+
# Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
99+
# This is especially recommended for binary packages to ensure reproducibility, and is more
100+
# commonly ignored for libraries.
101+
# https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
102+
#poetry.lock
103+
104+
# pdm
105+
# Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
106+
#pdm.lock
107+
# pdm stores project-wide configurations in .pdm.toml, but it is recommended to not include it
108+
# in version control.
109+
# https://pdm.fming.dev/#use-with-ide
110+
.pdm.toml
111+
112+
# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
113+
__pypackages__/
114+
115+
# Celery stuff
116+
celerybeat-schedule
117+
celerybeat.pid
118+
119+
# SageMath parsed files
120+
*.sage.py
121+
122+
# Environments
123+
.env
124+
.venv
125+
env/
126+
venv/
127+
ENV/
128+
env.bak/
129+
venv.bak/
130+
131+
132+
# Spyder project settings
133+
.spyderproject
134+
.spyproject
135+
136+
# Rope project settings
137+
.ropeproject
138+
139+
# mkdocs documentation
140+
/site
141+
142+
# mypy
143+
.mypy_cache/
144+
.dmypy.json
145+
dmypy.json
146+
147+
# Pyre type checker
148+
.pyre/
149+
150+
# pytype static type analyzer
151+
.pytype/
152+
153+
# Cython debug symbols
154+
cython_debug/
155+
156+
# PyCharm
157+
# JetBrains specific template is maintained in a separate JetBrains.gitignore that can
158+
# be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
159+
# and can be added to the global gitignore or merged into this file. For a more nuclear
160+
# option (not recommended) you can uncomment the following to ignore the entire idea folder.
161+
.idea/
162+
.vscode/
163+
164+
# macos
165+
*.DS_Store
166+
167+
# misc files
168+
data/
169+
dataset/
170+
runs/
171+
checkpoints/
172+
outputs/
173+
outputs
174+
samples/
175+
samples
176+
logs/
177+
pretrained_models/
178+
pretrained_models
179+
evaluation_results/
180+
cache/
181+
*.swp
182+
debug/
183+
184+
# Secret files
185+
hostfile
186+
run.sh
187+
gradio_cached_examples/
188+
wandb/
189+
190+
# vae weights
191+
eval/vae/flolpips/weights/
192+
193+
# npm
194+
node_modules/
195+
package-lock.json
196+
package.json
197+
198+
# PLLaVA
199+
tools/caption/pllava_dir/PLLaVA/
200+
201+
# vbench
202+
vbench
203+
!eval/vbench
204+
vbench2_beta_i2v

opensora_base/.pre-commit-config.yaml

+31
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,31 @@
1+
repos:
2+
3+
- repo: https://github.com/PyCQA/autoflake
4+
rev: v2.2.1
5+
hooks:
6+
- id: autoflake
7+
name: autoflake (python)
8+
args: ['--in-place']
9+
10+
- repo: https://github.com/pycqa/isort
11+
rev: 5.12.0
12+
hooks:
13+
- id: isort
14+
name: sort all imports (python)
15+
16+
- repo: https://github.com/psf/black-pre-commit-mirror
17+
rev: 23.9.1
18+
hooks:
19+
- id: black
20+
name: black formatter
21+
22+
- repo: https://github.com/pre-commit/pre-commit-hooks
23+
rev: v4.3.0
24+
hooks:
25+
- id: check-yaml
26+
- id: check-merge-conflict
27+
- id: check-case-conflict
28+
- id: trailing-whitespace
29+
- id: end-of-file-fixer
30+
- id: mixed-line-ending
31+
args: ['--fix=lf']

opensora_base/CONTRIBUTING.md

+100
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,100 @@
1+
# Contributing
2+
3+
The Open-Sora project welcomes any constructive contribution from the community and the team is more than willing to work on problems you have encountered to make it a better project.
4+
5+
## Development Environment Setup
6+
7+
To contribute to Open-Sora, we would like to first guide you to set up a proper development environment so that you can better implement your code. You can install this library from source with the `editable` flag (`-e`, for development mode) so that your change to the source code will be reflected in runtime without re-installation.
8+
9+
You can refer to the [Installation Section](./README.md#installation) and replace `pip install -v .` with `pip install -v -e .`.
10+
11+
### Code Style
12+
13+
We have some static checks when you commit your code change, please make sure you can pass all the tests and make sure the coding style meets our requirements. We use pre-commit hook to make sure the code is aligned with the writing standard. To set up the code style checking, you need to follow the steps below.
14+
15+
```shell
16+
# these commands are executed under the Open-Sora directory
17+
pip install pre-commit
18+
pre-commit install
19+
```
20+
21+
Code format checking will be automatically executed when you commit your changes.
22+
23+
## Contribution Guide
24+
25+
You need to follow these steps below to make contribution to the main repository via pull request. You can learn about the details of pull request [here](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests).
26+
27+
### 1. Fork the Official Repository
28+
29+
Firstly, you need to visit the [Open-Sora repository](https://github.com/hpcaitech/Open-Sora) and fork into your own account. The `fork` button is at the right top corner of the web page alongside with buttons such as `watch` and `star`.
30+
31+
Now, you can clone your own forked repository into your local environment.
32+
33+
```shell
34+
git clone https://github.com/<YOUR-USERNAME>/Open-Sora.git
35+
```
36+
37+
### 2. Configure Git
38+
39+
You need to set the official repository as your upstream so that you can synchronize with the latest update in the official repository. You can learn about upstream [here](https://www.atlassian.com/git/tutorials/git-forks-and-upstreams).
40+
41+
Then add the original repository as upstream
42+
43+
```shell
44+
cd Open-Sora
45+
git remote add upstream https://github.com/hpcaitech/Open-Sora.git
46+
```
47+
48+
you can use the following command to verify that the remote is set. You should see both `origin` and `upstream` in the output.
49+
50+
```shell
51+
git remote -v
52+
```
53+
54+
### 3. Synchronize with Official Repository
55+
56+
Before you make changes to the codebase, it is always good to fetch the latest updates in the official repository. In order to do so, you can use the commands below.
57+
58+
```shell
59+
git fetch upstream
60+
git checkout main
61+
git merge upstream/main
62+
git push origin main
63+
```
64+
65+
### 5. Create a New Branch
66+
67+
You should not make changes to the `main` branch of your forked repository as this might make upstream synchronization difficult. You can create a new branch with the appropriate name. General branch name format should start with `hotfix/` and `feature/`. `hotfix` is for bug fix and `feature` is for addition of a new feature.
68+
69+
```shell
70+
git checkout -b <NEW-BRANCH-NAME>
71+
```
72+
73+
### 6. Implementation and Code Commit
74+
75+
Now you can implement your code change in the source code. Remember that you installed the system in development, thus you do not need to uninstall and install to make the code take effect. The code change will be reflected in every new PyThon execution.
76+
You can commit and push the changes to your local repository. The changes should be kept logical, modular and atomic.
77+
78+
```shell
79+
git add -A
80+
git commit -m "<COMMIT-MESSAGE>"
81+
git push -u origin <NEW-BRANCH-NAME>
82+
```
83+
84+
### 7. Open a Pull Request
85+
86+
You can now create a pull request on the GitHub webpage of your repository. The source branch is `<NEW-BRANCH-NAME>` of your repository and the target branch should be `main` of `hpcaitech/Open-Sora`. After creating this pull request, you should be able to see it [here](https://github.com/hpcaitech/Open-Sora/pulls).
87+
88+
The Open-Sora team will review your code change and merge your code if applicable.
89+
90+
## FQA
91+
92+
1. `pylint` cannot recognize some members:
93+
94+
Add this into your `settings.json` in VSCode:
95+
96+
```json
97+
"pylint.args": [
98+
"--generated-members=numpy.* ,torch.*,cv2.*",
99+
],
100+
```

0 commit comments

Comments
 (0)