Hi: I am the maintainer of https://github.com/nexB/scancode-toolkit a tool that detects licenses...
I never knew of the https://github.com/CottageLabs/esprit/blob/master/setup.py#L14 Copyheart license.... but you also have an Apache license text at your root.

As an act mercy for me and my vain attempts to properly detect licenses, would you care to clarify this?

Some functions require anes_version because the syntax has changed between versions, e.g. the put_mapping function in raw:

put_mapping(connection, type=None, mapping=None, make_index=True, es_version="0.90.13"):

This is acceptable until you want to write a task which requires more than one connection simultaneously. It's conceivable that you might want to connect to more than one version of ES at a time - perhaps reindexing from a 0.9 connection to a 5.2 connection. Here, it would be nicer if the es_version were a property of the Connection object, because it will always be fixed for a given index.

Ideally it would be taken out of all function args and only read from the connection, but that's a breaking change.

There's a repo using it already (uniboard) under the CottageLabs organisation and I'd generally use it with new projects. Also I think DOAJ will be using this? (correct me if wrong ofc..)

This should prevent problems like being unable to copy over types which do not have id.exact in the document source. All documents have _id though.

Basically right now I have to do requirements.txt magic on projects that rely on this lib, instead of just referencing "esprit" in the install dependencies.

Example: https://github.com/CottageLabs/uniboard/blob/master/requirements.txt

I haven't done this before, I think you have @richard-jones ? Of course after any updates the version will have to be bumped and the package pushed up to pypi.

We can also keep using the requirements.txt method of course, just that it means changing the way any project that uses this library is installed. pip install -r requirements.txt instead of pip install -e . .

When you declare a query and attempt to run more than one task on it, it can be modified by esprit:

query = {'query': {'term': {'admin.application_status.exact': 'rejected'}}}

Then run a task which called iterate(...), such as tasks.dump(...) then it is changed for the next task that uses it:

query is now {'sort': [{'id': {'order': 'asc'}}], 'query': {'term': {'admin.application_status.exact': 'rejected'}}, 'from': 8000, 'size': 1000}

This can be fixed by either passing query.copy() into the task in the first place, or each task could be careful to only modify a copy of the query within their methods so the original is unaffected. I'm happy to make the code changes if you choose the latter option.