Add gdbm support (python 3.7)

[hmaarrfk]

Requires conda-forge/staged-recipes#6681

Closes #125

I got stuck doing something that required gdbm. I think that gdbm is required, so I decided to compile it.

I'll rerender after the package review to avoid noise in the commit.

Checklist

• Used a fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

[conda-forge-linter]

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

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[jakirkham]

Should we be including gdbm at runtime?

[hmaarrfk]

GOod question. My vote is no to keep GPL library out of the core dependencies.

[hmaarrfk]

An other reason would be to keep the python package lean. I'm sure there are many other options that could be added, but not everybody might need them. Since it wasn't really creating issues before, I assume that it is OK as is.

[jakirkham]

Have restarted CIs now that gdbm has been added.

[hmaarrfk]

I noticed pypy was built with gdbm. Do we need to defender it?

[hmaarrfk]

OMG. So sorry. I clicked the wrong button ...

[jakirkham]

All good.

Possibly. Maybe we should raise an issue on the PyPy feedstocks and see.

[hmaarrfk]

@conda-forge-admin, please rerender

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-webservice.

I tried to re-render for you, but it looks like there was nothing to do.

[conda-forge-linter]

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

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[jjhelmus]

Rather than creating a build of Python with the gdbm module what if a separate package was created that contained the _gdbm.so file in the lib-dyload or equivalent directory. Installing this package would enable the use of of the dbm.gnu module. This would nicely separation the GPL components.

This requires that the code that build be extension be extracted out the setup.py file in the Python source code but I'd be happy to help with this.

[hmaarrfk]

@jjhelmus I would be in favor of that

Honestly, I was just going to create the same python package but omit the strict dependency on the gdbm package.

But to your idea, could we simply create a split package where by one output, python-gdbm just copies lib/python3.7/lib-dynload/_gdbm.cpython-37m-x86_64-linux-gnu.so into the prefix, while
python calls make install and removes the file lib/python3.7/lib-dynload/_gdbm.cpython-37m-x86_64-linux-gnu.so

[h-vetinari]

Any update on this effort? :)