Fix issue with path when mvs is installed as a package#607
Fix issue with path when mvs is installed as a package#607Bachibouzouk merged 24 commits intodevfrom
Conversation
296c9d0 to
672b8d6
Compare
|
@smartie2076 - it could have been split in two PRs, but some features were depending on one another so I grouped everything under one PR |
The eland logo and styles.css files are added as data_files to the package. A function will copy them from the package to a provided path.
Do not provide __name__ to dash.Dash fixes the assets loading problem because __name__ is now within the installed package and not anymore linked to current directory
0a6e7c8 to
1d46514
Compare
smartie2076
left a comment
There was a problem hiding this comment.
One comment to the installation instructions: Those are user-focused in README.md, aren`t they? Is there a link somewhere that points to the dev installation procedure, or is there no difference?
Wouldnt it make sense to directly read from the README.rst and load the installation procedure into Installation.rst?
| className="cell imp_info", | ||
| children=[ | ||
| html.P(f"MVS Release: {version_num} ({version_date})"), | ||
| html.P(f"Branch-id: {branchID}"), |
There was a problem hiding this comment.
But printing the used branch in the report was important for me, so that we do not mess up comparing two scenarios that are used with different dev versions or something. Is removing it necessary?
There was a problem hiding this comment.
If you run the simulation after installing the package with pip, you might run a simulation not from the root of this repository, therefore the code to fetch the branch id of this repository fails because you are not anymore within a repository when you run the code.
Ultimately, the version number is the only thing which matters (it is uniquely mapped to a commit id in the master branch of the repo) as on pip you cannot have two release with same version numbers, you can only bump version number up.
If you want to keep the branch-id feature, we should pack this into a function of utils which detects if the person executing the code does it from the root of the repository or not and provide, or not, the branch id
There was a problem hiding this comment.
Mhm... okay. Actually, as the end-user will use the simplest way to install the MVS, we probably do not need to print the branch-id.
For devs: When working on the dev branch, we have the same version number as the master release, dont we? Could we not bump the version number of dev to something like vX.Y.Z.dev? and then we are at least warned when we compare dev to real releases. Additionally, we can then check the simulation date to guess if large changes might already have been applied to dev...
There was a problem hiding this comment.
We can reintroduce the ID in a subsequent PR what do you say @smartie2076 ?
There was a problem hiding this comment.
You mean as in "introduce in another way"? Sounds fine. Can you create an issue noting down your thoughts?
Otherwise it would be better to just revieve it now.
| - If default folder does not exist when code is executed, example simulation's inputs are used from package_data (#607) | ||
|
|
||
| ### Removed | ||
| - Remove reference to git branch ID in the report (#607) |
There was a problem hiding this comment.
Because you are within this repository only when you execute the code from somewhere else there is no repository
There was a problem hiding this comment.
Ok, I got the idea. I hope there wont be too many mess-ups when we as devs simulate the pilots with the dev version. Maybe we should just prohibit people to do that xD
|
Does this PR address that currently the tables are not displayed in the pdf report? See here: #606 (comment) |
I can see the tables with code from this PR |
"Tables with code" You mean, the tables with values? Nice. |
--> "I can see tables" + "with the code from this PR" |
Fix #594, Fix #598
Changes proposed in this pull request:
setup.pymvs_report.pyintomulti_vector_simulator.cli:reportmvs_toolandmvs_reportin ´setup.py´To be able to use package_data, one has to install the package locally
python setup.py install, for developerspython setup.py developorpip install -e .. However this does not install package_data properly, so developers cannot use complete default values. They can use ´mvs_tool -i tests/inputs´ when being in the root of the repository (maybe need to add this in CONTRIBUTING, but after we merge #601)The following steps were realized, as well (if applies):
black . --exclude docs/)EXECUTE_TESTS_ON=master pytest)For more information on how to contribute check the CONTRIBUTING.md.