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.

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

Test lower bounds specified in main dependencies #70

Merged
merged 19 commits into from
Jan 23, 2024
Merged

Test lower bounds specified in main dependencies #70

merged 19 commits into from
Jan 23, 2024

Conversation

jdawang
Copy link
Contributor

@jdawang jdawang commented Jan 3, 2024

Description

This is a feature that allows users to specify packages that they want to test lower bounds of. If specified in an edgetest environment, edgetest will:

  1. Setup the environment, like for the upgrade use case.
  2. Install the lower bounds of packages, where the lower bounds of packages are parsed from the main dependencies, only with the >= specifier. This is the initial implementation and we can handle extras later.
  3. Run the unit tests, as in the upgrade case.
  4. Report if tests passed or failed.

Currently, there is no:

  • Parsing of extras.
  • Parsing of any requirement specifiers that do not contain >=, as this would require a search.
  • Automatic updating requirement files as this would require a search.
  • Default environments for each dependency and one with all requirements as for the upgrade case.
  • Handling if a package is specified with extras in the dependencies and without in lower or vice versa. Might want to add this in right now, but can also leave for later and document.

So, no testing of lower bounds will be done unless explicitly asked for by the user.

There are also some changes that I made to get it to work:

  • Schema for edgetests.envs environment now has a new section lower that is mutually exclusive with `upgrade.
  • When setting up the environment, edgetest will now soft fail and report setup unsuccessful for that environment instead of just exiting with an exception right away. In practice, I ran into issues testing on packages with very outdated versions that they can't even be installed.
  • Which leads to a new column in the report, Setup successful, which indicates whether the environment could be set up and everything installed alright.
  • Another new column in the report for the lowered packages.

Closes #69

Type of change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

Checklist:

  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes
  • New and existing integration tests pass locally with my changes
  • Any dependent changes have been merged and published in downstream modules

Copy link
Member

@fdosani fdosani left a comment

Choose a reason for hiding this comment

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

@jdawang This is great! Thanks for the effort. I have one question, but I think your docs actually answer my question. Great experimental feature!

edgetest/utils.py Show resolved Hide resolved
Copy link
Contributor

@ak-gupta ak-gupta left a comment

Choose a reason for hiding this comment

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

Great work! A couple optional fixes but I appreciate the extensive testing and documentation you put into this.

edgetest/core.py Show resolved Hide resolved
edgetest/core.py Outdated
Comment on lines 28 to 29
lower : list
The list of packages to install lower bounds.
Copy link
Contributor

Choose a reason for hiding this comment

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

Documentation note: reading the utilities, this is a list of the packages to be lowered alongside the lower bound, correct? I.e.

[
    "pandas==1.5.1",
]

instead of

["pandas",]

Should we add that to the docs where lower is an input? It's different than the format of upgrade.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah that's a good catch. In the config, it's just like upgrade, but in TestPackage, the config is already parsed to provide the package to be lowered alongside the lower bound.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah not a huge deal since it's not user facing. Might save us some confusion down the road though.

Comment on lines 223 to 234
output["envs"][-1]["lower"] = "\n".join(
f"{pkg_name}=={lower_bound}"
for pkg_name, lower_bound in get_lower(
config.get("options", "install_requires")
).items()
if _isin_case_dashhyphen_ins(
pkg_name, output["envs"][-1]["lower"].split("\n")
)
and lower_bound is not None
# TODO: Emit warning if lower_bound is None but package is in lower
# TODO: Parse through extra requirements as well to get lower bounds
)
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm finding this loop a bit difficult to read. What if we split it out a bit? Something along the lines of

Suggested change
output["envs"][-1]["lower"] = "\n".join(
f"{pkg_name}=={lower_bound}"
for pkg_name, lower_bound in get_lower(
config.get("options", "install_requires")
).items()
if _isin_case_dashhyphen_ins(
pkg_name, output["envs"][-1]["lower"].split("\n")
)
and lower_bound is not None
# TODO: Emit warning if lower_bound is None but package is in lower
# TODO: Parse through extra requirements as well to get lower bounds
)
output["envs"][-1]["lower"] = ""
for pkg_name, lower_bound in get_lower(config.get("options", "install_requires").items():
if (
_isin_case_dashhyphen_ins(pkg_name, output["envs"][-1]["lower"].split("\n")) and lower_bound is not None
):
output["envs"][-1]["lower"] += f"{pkg_name}=={lower_bound}\n"
# TODO: Emit warning if lower_bound is None but package is in lower
# TODO: Parse through extra requirements as well to get lower bounds

@jdawang jdawang marked this pull request as ready for review January 19, 2024 21:10
@jdawang
Copy link
Contributor Author

jdawang commented Jan 19, 2024

Made a couple simplifying changes @fdosani and @ak-gupta and I think it is ready now.

Copy link
Contributor

@ak-gupta ak-gupta left a comment

Choose a reason for hiding this comment

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

LGTM! Great work!

@jdawang jdawang merged commit ab01755 into dev Jan 23, 2024
11 checks passed
@jdawang jdawang deleted the parse-lower branch January 23, 2024 14:53
@jdawang jdawang restored the parse-lower branch January 23, 2024 17:07
@jdawang jdawang mentioned this pull request Feb 16, 2024
12 tasks
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.

Test lower bounds
3 participants