relax the hard dependencies a bit

[jkogler-cloudflight]

Alternative implementation to #36 (as solution to issue #34 and issue #45).

I don't think that there have been any significant changes in black since version 19, so I just relaxed the requirements a little bit by setting the >= instead of ==, and all the tests still pass.

---

As an alternative option, we could just pin the versions in dev and remove them from the normal dependencies, but additionally add them as optional dependencies via extras_require in the setup.py. Then you could explicitly install pipenv-setup with pip install 'pipenv-setup[black]' or pip install 'pipenv-setup[autopep8]'. However that would break the normal pip install pipenv-setup, as it doesn't install any of the tools.

Alternatively, it should be possible to always require autopep8, and only to the optional dependency for black, in case somebody wants to use it explicitly.

[jkogler-cloudflight]

@bryant-finney

[bryant-finney]

@jkogler-cloudflight I believe this discussion on PR #75 relates to this change. @jshwi accurately pointed out that requiring allow_prereleases = true will likely break any projects that rely on automated scripts to install pipenv-setup using pipenv (but don't already set that option).

Can you confirm that removing allow_prereleases = true doesn't result in any dependency resolution errors?

[bryant-finney]

PS I'm currently working on this MR in a fork on GitLab ; might it be possible to cherry-pick or rebase this PR onto a branch in that project? Then we could at least use the CI/CD jobs I've implemented thus far.

If you're interested just request access or shoot me your GitLab username, and I'll be happy to add you as a contributor!

[jkogler-cloudflight]

@jshwi accurately pointed out that requiring allow_prereleases = true will likely break any projects that rely on automated scripts to install pipenv-setup using pipenv (but don't already set that option).

That confused me for a while. As the allow_prerelease = true setting is part of the packaged wheel of pipenv-setup.
But I guess the problem is, that the dependency of black relaxed in the wheel, and then if you install pipenv-setup, pipenv refuses to install black as the prerelease = true is not set.

Yesterday, when I made the PR, I had to install black with pipenv install black --pre, otherwise pipenv refused to install it.
However strangely, now it doesn't require it anymore. Even after removing the virtual environment. Not sure why it suddenly works. Maybe the new pipenv version, that was released yesterday fixed something?

I've removed the allow-prerelease = true line. Everything still works, at least for me.
I'll make a MR on the Gitlab instance.

My Gitlab user is https://gitlab.com/jakobkogler . Any particular reason for switching to Gitlab? Github has pretty good (and also free) CI/CD support with their Github Action workflows.

[jshwi]

@jkogler-cloudflight
from what I gather @bryant-finney hasn't made a permanent migration to gitlab, but is more familiar with its CI.

I'm working on pushing a .github/workflow file currently. I think once the bugs are ironed out he'll merge/rebase it back onto this repo's master branch. I've added a gitlab remote to keep up to date

[bryant-finney]

@jkogler-cloudflight oh fascinating, I need to check out the new pipenv release!

@jshwi is correct re: GitLab. If a permanent migration is something that contributors would be interested in, I'm certainly open to it. However, I think the only real reason for using GitLab CI (initially) is just because I've done similar pipelines for tox before, making it faster for me to get something running 🙂

@jkogler-cloudflight I triggered a pipeline on your fork through the GitLab UI; the CI config uses the project container registry to provide Docker images for each python version (thus avoiding docker's pull rate limits), and it's configured to only push/update those images on manual triggers or scheduled pipelines.

Now that your fork's registry provides those images, the jobs all pass 🚀

[Madoshakalaka]

Thanks! black is now gated as an extra dependency and it's fixed to its latest minor release.