Create PULL_REQUEST_TEMPLATE.md [skip ci]

[183amir]

@conda-forge/core I create a pull request template. What do you think?

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I was trying to look for recipes to lint for you, but couldn't find any.
Please ping the 'conda-forge/core' team (using the @ notation in a comment) if you believe this is a bug.

[183amir]

@ocefpaf I opened a new one here.

[ocefpaf]

@ocefpaf I opened a new one here.

No problems. Please see me comments on #549, they are minor easy to fix.

@183amir I believe we can put the template files (PR and Issues) in a .github directory to avoid the clutter.

[jakirkham]

Nice idea. Will try to review later.

I believe one can use CONTRIBUTING.md and GitHub will link it to the top of every issue and PR.

[183amir]

True. There is also ISSUE_TEMPLATE.md

[ocefpaf]

I would not worry about CONTRIBUTING.md and ISSUE_TEMPLATE.md right now. However, this PR template you put together is very useful and long overdue! Let's get that on the repo ASAP.

[jakirkham]

Not sure that we should have a hard limit on this. For some people, dumping everything in one go is the easiest way to get started. Admittedly, we may end up breaking it up in the end, but it would be better for reviewers and contributors to work together to strike a healthy balance for this on a case-by-case basis.

Maybe some wording can be added to encourage a small number of recipes.

[jakirkham]

Took a look. Largely in favor of most of it. Some things need tweaks. Here are a couple big points.

• Python install: we should stick with the status quo until we make a decision on this ( Python install line standard #528 ).
• Compilers: same story (though admittedly that changed very recently).
• Example recipe: should update to be a better representation of what we do now.

[jakirkham]

I believe we can put the template files (PR and Issues) in a .github directory to avoid the clutter.

👍 Correct. See ref.

[183amir]

I will be out till Monday. Please feel free to open another pull request based on this one and add your comments directly there if you want to merge this as soon as possible.

[jakirkham]

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.

1. The compiler didn't mess something up.
2. Something didn't go wrong in the linking stage.
3. That the package will work in the environment defined.

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 run_test.py to do a few more things, but that will probably be determined after it is a feedstock.

In short, I don't think this should be a hard requirement for pure Python packages.

[183amir]

@jakirkham since you have written the guidelines and this is really urgent for people adding adding new recipes, why don't you create another pull request based on this one and add your comments directly to it? so that we can have this merged as fast as possible. We can always iterate this later.

[ocefpaf]

Closing as "stale."