Skip to content

chore: explicitly import gitlab.v4.objects/cli #1310

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.

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

Merged
merged 1 commit into from
Feb 22, 2021
Merged

chore: explicitly import gitlab.v4.objects/cli #1310

merged 1 commit into from
Feb 22, 2021

Conversation

JohnVillalovos
Copy link
Member

@JohnVillalovos JohnVillalovos commented Feb 21, 2021

As we only support the v4 Gitlab API, explicitly import
gitlab.v4.objects instead of dynamically importing it depending on the
API version.

This has the added benefit of mypy being able to type check the Gitlab
init() function as currently it will fail if we enable type
checking of init() it will fail.

@JohnVillalovos JohnVillalovos changed the title chore: explicitly import gitlab.v4.objects WIP: chore: explicitly import gitlab.v4.objects Feb 21, 2021
@codecov-io
Copy link

codecov-io commented Feb 21, 2021

Codecov Report

Merging #1310 (adddbef) into master (5cc60d5) will decrease coverage by 0.03%.
The diff coverage is 75.00%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #1310      +/-   ##
==========================================
- Coverage   80.76%   80.72%   -0.04%     
==========================================
  Files          69       69              
  Lines        3623     3627       +4     
==========================================
+ Hits         2926     2928       +2     
- Misses        697      699       +2     
Flag Coverage Δ
unit 80.72% <75.00%> (-0.04%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
gitlab/client.py 80.00% <75.00%> (-0.35%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5cc60d5...adddbef. Read the comment docs.

@JohnVillalovos JohnVillalovos changed the title WIP: chore: explicitly import gitlab.v4.objects chore: explicitly import gitlab.v4.objects Feb 21, 2021
@JohnVillalovos JohnVillalovos changed the title chore: explicitly import gitlab.v4.objects WIP: chore: explicitly import gitlab.v4.objects Feb 21, 2021
@JohnVillalovos JohnVillalovos marked this pull request as draft February 21, 2021 03:29
@JohnVillalovos JohnVillalovos changed the title WIP: chore: explicitly import gitlab.v4.objects chore: explicitly import gitlab.v4.objects Feb 21, 2021
@JohnVillalovos JohnVillalovos marked this pull request as ready for review February 21, 2021 17:43
Copy link
Member

@nejch nejch left a comment

Choose a reason for hiding this comment

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

I just have 1 comment, currently we still dynamically import in the cli module:

cli_module = importlib.import_module("gitlab.v%s.cli" % config.api_version)

So IMO I'd change that too for consistency.

From a quick grep there's also this, might only be an issue later though, with objects:

self.__dict__["_module"] = importlib.import_module(module_name)

Otherwise, this also helps by not confusing tools like pyinstaller/cx_freeze with dynamic imports so you don't need hooks for standalone executables. And according to https://docs.gitlab.com/ee/api/,

GraphQL co-exists with the current v4 REST API. If we have a v5 API, this should be a compatibility layer on top of GraphQL.

So this makes sense to me, one if/elif block at some point in the future shouldn't hurt, people do it all the time for OS-dependent imports 😄 /cc @max-wittig

@JohnVillalovos JohnVillalovos marked this pull request as draft February 22, 2021 00:05
@JohnVillalovos
Copy link
Member Author

I just have 1 comment, currently we still dynamically import in the cli module:

cli_module = importlib.import_module("gitlab.v%s.cli" % config.api_version)

So IMO I'd change that too for consistency.

Done.

From a quick grep there's also this, might only be an issue later though, with objects:

self.__dict__["_module"] = importlib.import_module(module_name)

I'm not quite sure what to do there 😟

@JohnVillalovos JohnVillalovos marked this pull request as ready for review February 22, 2021 00:37
@JohnVillalovos JohnVillalovos changed the title chore: explicitly import gitlab.v4.objects chore: explicitly import gitlab.v4.objects/cli Feb 22, 2021
@JohnVillalovos JohnVillalovos requested a review from nejch February 22, 2021 00:37
As we only support the v4 Gitlab API, explicitly import
gitlab.v4.objects and gitlab.v4.clie instead of dynamically importing
it depending on the API version.

This has the added benefit of mypy being able to type check the Gitlab
__init__() function as currently it will fail if we enable type
checking of __init__() it will fail.

Also, this also helps by not confusing tools like pyinstaller/cx_freeze with
dynamic imports so you don't need hooks for standalone executables. And
according to https://docs.gitlab.com/ee/api/,

    "GraphQL co-exists with the current v4 REST API. If we have a v5 API, this
    should be a compatibility layer on top of GraphQL."
@nejch nejch merged commit 8c58b07 into python-gitlab:master Feb 22, 2021
@JohnVillalovos JohnVillalovos deleted the jlvillal/v4_only branch February 24, 2021 01:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants