-
-
Notifications
You must be signed in to change notification settings - Fork 5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create PULL_REQUEST_TEMPLATE.md [skip ci] #550
Changes from all commits
89ccae1
33e9408
4ae2969
aaf53d9
99c0472
6d19f41
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,46 @@ | ||
Recipes added with this pull request (We prefer to have one pull request per package): | ||
|
||
- package1 | ||
- package2 | ||
|
||
I have checked the following in my recipes: | ||
* [ ] My files end with only 1 newline character, no more, no less. | ||
* [ ] My recipe follow the same style as [example](https://github.com/conda-forge/staged-recipes/blob/master/recipes/example/meta.yaml) as much as possible. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We might need to clean that up to match the style we want first. It fits an older acceptable style. Also, we have been discussing having a few, which we should work on somewhere. |
||
* [ ] The license field also specifies the number of the license if applicable (e.g. `GPLv3` instead of `GPL` or `BSD 3-clause` instead of `BSD`). | ||
* [ ] My recipe has tests. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should we be a bit more specific about what acceptable tests are? For instance, running |
||
* [ ] I have looked at [pinned packages](https://github.com/conda-forge/staged-recipes/wiki/Pinned-dependencies) and pinned those packages as stated. | ||
* [ ] The `summary` just explains the package and does not include the package name. (e.g. Instead of saying `Jupyterhub is a multi-user server for Jupyter notebooks` just say `Multi-user server for Jupyter notebooks`) | ||
|
||
If you build for Windows too: | ||
* [ ] I have read [VC features](https://github.com/conda-forge/staged-recipes/wiki/VC-features) and implemented. | ||
|
||
If recipe uses make or cmake or ctest: | ||
* [ ] I have also added `make check` or similar if applicable. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sorry hadn't gotten here yet. This looks good. |
||
|
||
If recipe builds a library: | ||
* [ ] I have enabled both static and shared libraries. | ||
|
||
If recipe builds some C/C++: | ||
* [ ] I have not included `gcc` or `libgcc` in `requirements`. Exceptions can be made but must be tested first with `gcc`/`clang` that is already installed in our CI machines. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Would rephrase. Currently Fortran and OpenMP are ok uses of the packages. So, we should make an exception. Though this is something we strive to eliminate. |
||
|
||
If it is a Python PyPI package: | ||
* [ ] I have used `python` to install it and my recipe has these elements: | ||
```yaml | ||
build: | ||
script: python setup.py install --single-version-externally-managed --record=record.txt | ||
requirements: | ||
build: | ||
- python | ||
- setuptools | ||
run: | ||
- python | ||
``` | ||
* [ ] Test commands such as `nosetests package` or `py.test` are added: | ||
```yaml | ||
test: | ||
requires: | ||
- nose | ||
|
||
commands: | ||
- nosetests -sv package | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. IMHO the point of testing is not really to run CI for the packages that are given to us. Instead it is here to guarantee the following things.
The first two don't really apply to pure Python packages so let's ignore that for now. As far as solving the last one, importing modules seems to be sufficient for the most part. Running the full test suite is something the developer(s) hopefully are doing on releases at least if not during development as part of CI. Thus, there isn't really much value in us doing it to for pure Python packages. If the Python code does have compiled portions, that is a totally different story. In the end, there may be a few packages that need something like In short, I don't think this should be a hard requirement for pure Python packages. |
||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not clear on what this listing is accomplishing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It helps to see which packages are being added without having to go through the "files changed" tab.
P.S. I pushed a new commit taking your comments in consideration.