In short: we want to get rid of requirements.txt files in favour of using Pipenv.
If we want to keep the inter-linking approach we have now, we'll need some extension to Pipenv. I've opened up a ticket on their Gitlab to discuss this.
Alternatively, we could rethink our strategy and rework Pillar and its extensions more into proper Python packages, and install them as such. This might require us to run our own Pypi-like service, which is totally possible.
Something we can't tackle on very short notice, so let's discuss the details here so we remember them later.
In short: we want to get rid of `requirements.txt` files in favour of using Pipenv.
If we want to keep the inter-linking approach we have now, we'll need some extension to Pipenv. I've opened up a [ticket on their Gitlab](https://github.com/pypa/pipenv/issues/2798) to discuss this.
Alternatively, we could rethink our strategy and rework Pillar and its extensions more into proper Python packages, and install them as such. This might require us to run our [own Pypi-like service](https://www.devpi.net/), which is totally possible.
Something we can't tackle on very short notice, so let's discuss the details here so we remember them later.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
In short: we want to get rid of
requirements.txtfiles in favour of using Pipenv.If we want to keep the inter-linking approach we have now, we'll need some extension to Pipenv. I've opened up a ticket on their Gitlab to discuss this.
Alternatively, we could rethink our strategy and rework Pillar and its extensions more into proper Python packages, and install them as such. This might require us to run our own Pypi-like service, which is totally possible.
Something we can't tackle on very short notice, so let's discuss the details here so we remember them later.
Added subscribers: @dr.sybren, @fsiddi