Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

relax the hard dependencies a bit #78

Closed
wants to merge 2 commits into from
Closed

relax the hard dependencies a bit #78

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
2035230
relax the hard dependencies a bit
jkogler-cloudflight Nov 9, 2021
271a739
Remove allowing prerelease
jkogler-cloudflight Nov 10, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 12 additions & 10 deletions Pipfile
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,21 +11,23 @@ pytest-cov = "~=2.7"
pytest-datadir = "~=1.3"
pytest-xdist = "~=1.29"
tox = "~=3.14"
autopep8 = "~=1.4"

[packages]
pipfile = "~=0.0"
black = {markers = "python_version>='3.6'",version = "==19.10b0"}
colorama = "~=0.4"
packaging = "~=20.0"
requirementslib = "~=1.5"
vistir = "~=0.4"
autopep8 = {markers = "python_version<'3.6'",version = "~=1.4"}
six = "~=1.12"
typing = {markers = "python_version<'3.7'", version = "~=3.7"}
pipfile = ">=0.0"
black = {markers = "python_version>='3.6'",version = ">=19.10b0"}
colorama = ">=0.4"
packaging = ">=20.0"
requirementslib = ">=1.5"
vistir = ">=0.4"
autopep8 = {markers = "python_version<'3.6'",version = ">=1.4"}
six = ">=1.12"
typing = {markers = "python_version<'3.7'", version = ">=3.7"}
chardet = ">=3.0.0, <=5.0.0"

[scripts]
# use this to sync this pipfile to setup.py, explained in CONTRIBUTING.md
# `$ pipenv run sync-deps`
sync-deps = 'python -m pipenv_setup sync --dev --pipfile'

[pipenv]
allow_prereleases = true
Copy link
Collaborator

@bryant-finney bryant-finney Nov 9, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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!

Copy link
Author

@jkogler-cloudflight jkogler-cloudflight Nov 10, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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 🚀

Loading