new recipe for ConnectionPool

[jmeppley]

Checklist

• Title of this PR is meaningful: e.g. "Adding my_nifty_package", not "updated meta.yaml"
• License file is packaged (see here for an example)
• Source is from official source
  The original developer hasn't responded to past pull requests, so I forked the project. This is a small little thing, but I think it could be useful to keep available as a separate project rather than just folding the code into where I'm going to use it.
• Package does not vendor other packages. (If a package uses the source of another package, they should be separate packages or the licenses of all packages need to be packaged)
• If static libraries are linked in, the license of the static library is packaged.
  (N/A)
• Build number is 0
• A tarball (url) rather than a repo (e.g. git_url) is used in your recipe (see here for more details)
• GitHub users listed in the maintainer section have posted a comment confirming they are willing to be listed there

Attn: @conda-forge/help-python

[conda-forge-linter]

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

I wanted to let you know that I linted all conda-recipes in your PR (recipes/connectionpool) and found some lint.

Here's what I've got...

For recipes/connectionpool:

• The top level meta keys are in an unexpected order. Expecting ['package', 'source', 'build', 'requirements', 'about'].
• The license item is expected in the about section.
• The recipe could do with some maintainers listed in the extra/recipe-maintainers section.
• The recipe must have some tests.

[scopatz]

Please remove comments

[scopatz]

This should be host

[scopatz]

you probably need pip here

[scopatz]

You probably don't need two about sections

[synapticarbors]

I ended up just giving you what I think is a complete sample of what the recipe should look like. Also greetings from a fellow Haverford grad!

[synapticarbors]

Also since the original package of the same name is up on pypi.io (https://pypi.org/project/connection-pool/) and you have a fork, I think we might want to be careful with the naming of the package so that there isn't confusion, unless the original project you forked from is known to no longer be developed and this is the official new branch of development.

[jmeppley]

Thanks for the feedback, @synapticarbors and @scopatz.

I just noticed that I changed the package name slightly from the original pip. I meant to use the same name.

I'm not sure of the etiquette of taking on this project. I don't think it needs to be forked, but It seems like the original developer might have abandoned it, although it's only been a couple years. I've reached out to them and can wait a bit to see if I get a response.

Do either of you have any suggestions on how to proceed?

Either way, I should probably close this and re-open with either the pip name or a sufficiently different name.