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

Make status target always shows outdated #100

Open
cassava opened this issue Jun 29, 2022 · 3 comments
Open

Make status target always shows outdated #100

cassava opened this issue Jun 29, 2022 · 3 comments
Labels
bug Something isn't working enhancement New feature or request

Comments

@cassava
Copy link
Contributor

cassava commented Jun 29, 2022

I realize that make status says that it's approximate, because it compares the package age with all the files in the package directory, but this is causing confusion for our users.

There are several issues at play here though regarding ok vs outdated:

  1. make status may not represent the package you're interested in, since there might be one linked to boost/1.68 that is ancient but another that is linked to boost/1.78.0 that is up-to-date. How are we even to know which configuration the user is interested in?
  2. make status may not be accurate, since we modified a file that is not contributing to the package (eg. README), making it look as though the package is outdated, when it is not.

Really, the whole point of make status is the following:

A. Ensure that I don't forget to export changes to recipe or sources.
B. Ensure that I don't forget to build a package if it's outdated.
C. Tell me if this package is in editable mode or not.

It would be easy enough to solve problems (1) and (2) with cloe-launch. However, cloe-launch cannot by nature address (A) and addressing (C) doesn't make much sense for cloe-launch.


Proposed solution:

  • Use ok? and outdated? in output from make status
  • Add check to cloe-launch to check if package is out-of-date (how?)
  • Print warning in cloe-launch when a user is using out-of-date packages
  • Fix Python stack-trace when a package does not exist

This last point would fix the unreadable output from cloe-launch when the requirements are not available.

@cassava
Copy link
Contributor Author

cassava commented Jun 29, 2022

Case in point:

make package-auto followed by make status:

$ make status
ok       : fable/0.19.0-nightly@cloe/develop
outdated : cloe-runtime/0.19.0-nightly@cloe/develop
outdated : cloe-models/0.19.0-nightly@cloe/develop
outdated : cloe-oak/0.19.0-nightly@cloe/develop
ok       : cloe-engine/0.19.0-nightly@cloe/develop
outdated : cloe-plugin-gndtruth-extractor/0.19.0-nightly@cloe/develop
outdated : cloe-plugin-basic/0.19.0-nightly@cloe/develop
outdated : cloe-plugin-speedometer/0.19.0-nightly@cloe/develop
outdated : cloe-plugin-virtue/0.19.0-nightly@cloe/develop
outdated : cloe-plugin-mocks/0.19.0-nightly@cloe/develop
outdated : cloe-plugin-noisy-sensor/0.19.0-nightly@cloe/develop
outdated : cloe-plugin-minimator/0.19.0-nightly@cloe/develop

The fable and cloe-engine are only showing ok because I ran make -C fable package and make -C engine package.

@cassava
Copy link
Contributor Author

cassava commented Jun 29, 2022

One thing which would solve (A) is the use of lockfiles with make status. This would involve creating a lockfile for each package right now though... which would increase the time to run for make status significantly.

cassava added a commit that referenced this issue Jun 29, 2022
It works like this:

    make LOCKFILE_SOURCE=../conanfile.py all

when you are in sub-directory and you want to use some other
profile for dependency resolution etc.

The lockfile source can also be used for the status target:

    make LOCKFILE_SOURCE=../conanfile.py status

This will result in a different answer to the case where no lockfile is
specified.

This partially resolves issue #100.
@cassava
Copy link
Contributor Author

cassava commented Jun 29, 2022

The commit referenced above solves (1) by adding LOCKFILE_SOURCE support to status. This makes it orthogonal with all the other targets.

cassava added a commit that referenced this issue Jul 7, 2022
It works like this:

    make LOCKFILE_SOURCE=../conanfile.py all

when you are in sub-directory and you want to use some other
profile for dependency resolution etc.

The lockfile source can also be used for the status target:

    make LOCKFILE_SOURCE=../conanfile.py status

This will result in a different answer to the case where no lockfile is
specified.

This partially resolves issue #100.
cassava added a commit that referenced this issue Jul 7, 2022
It works like this:

    make LOCKFILE_SOURCE=../conanfile.py all

when you are in sub-directory and you want to use some other
profile for dependency resolution etc.

The lockfile source can also be used for the status target:

    make LOCKFILE_SOURCE=../conanfile.py status

This will result in a different answer to the case where no lockfile is
specified.

This partially resolves issue #100.
cassava added a commit that referenced this issue Jul 12, 2022
It works like this:

    make LOCKFILE_SOURCE=../conanfile.py all

when you are in sub-directory and you want to use some other
profile for dependency resolution etc.

The lockfile source can also be used for the status target:

    make LOCKFILE_SOURCE=../conanfile.py status

This will result in a different answer to the case where no lockfile is
specified.

This partially resolves issue #100.
cassava added a commit that referenced this issue Jul 12, 2022
It works like this:

    make LOCKFILE_SOURCE=../conanfile.py all

when you are in sub-directory and you want to use some other
profile for dependency resolution etc.

The lockfile source can also be used for the status target:

    make LOCKFILE_SOURCE=../conanfile.py status

This will result in a different answer to the case where no lockfile is
specified.

This partially resolves issue #100.
@cassava cassava changed the title make status always shows outdated Make status target always shows outdated Dec 6, 2023
@cassava cassava added bug Something isn't working enhancement New feature or request labels Dec 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant