Skip to content
New issue

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

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

Already on GitHub? # to your account

Why is there an upper bound in the packaging requirement? (packaging<22) #276

Closed
npatki opened this issue Mar 30, 2023 · 1 comment · Fixed by #297
Closed

Why is there an upper bound in the packaging requirement? (packaging<22) #276

npatki opened this issue Mar 30, 2023 · 1 comment · Fixed by #297
Assignees
Labels
maintenance Tasks related to infrastructure & dependencies question General question about the software
Milestone

Comments

@npatki
Copy link
Contributor

npatki commented Mar 30, 2023

Update (May 16, 2023)

Seems like we no longer even use the packaging library, so this dependency can be removed.

Description

The current version of CTGAN (0.7.1) includes the packaging library, with the following versioning requirements:

    'packaging>=20,<22',

But the packaging library has released a version 23 in January 2023.

As a user, I may have other libraries in my environment that depend on this latest version. Now, I can no longer install SDV or CTGAN due to packaging requirement. (eg. See SDV issue 1345)

Proposed Solution

We should explore whether it's really necessary to have an upper bound in packaging. As this is a core Python utility, we should see if they offer backwards compatibility. If so, this would simplify the requirements:

    'packaging>=20',
@npatki npatki added question General question about the software maintenance Tasks related to infrastructure & dependencies labels Mar 30, 2023
@npatki
Copy link
Contributor Author

npatki commented Mar 30, 2023

It seems like the only reason we need packaging it to compare version numbers (see line).

from packaging import version

...

        if version.parse(torch.__version__) < version.parse('1.2.0'):

Possible solutions:

  1. This will probably continue to work on higher versions, so it may be fine to uncap it
  2. Or alternatively, just upgrade it to include 23 for now (after checking it)
  3. Since the only intended usage is to compare to 1.2.0, we can just write our own method for this for now -- and get rid of the packaging dependency altogether.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
maintenance Tasks related to infrastructure & dependencies question General question about the software
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants