Use setting for gbasf2 setup file instead of install directory #162
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov ReportPatch coverage:
📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more Additional details and impacted files@@ Coverage Diff @@
## main #162 +/- ##
==========================================
+ Coverage 59.20% 60.47% +1.27%
==========================================
Files 23 23
Lines 1554 1594 +40
==========================================
+ Hits 920 964 +44
+ Misses 634 630 -4
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report in Codecov by Sentry. |
Usage of `gbasf2_install_directory` will cause a pending deprecation warning,
but it can still be used and then the corresponding path to
the `setup.sh` will be derived.
* Rationale:
b2luigi only needs to know which file to source to get the correct
environment. The location or name of that file withing a gbasf2 install
directory can change between gbasf2 releases. Providing the file path directly
results in more simplicity and flexibility.
* Additional enhancement:
In addition, the setting is now only obtained in the `Gbasf2Process` class and
not in the free helper functions, which now get the value via function
arguments. With this, the setting can be provided via a Task class attribute and
the value from the Task attribute will be used everywhere as expected.
This resulted in much more boiler plate code, but also it made my helper
function much more usable as library function without b2luigi settings.
95d7b40 to
715b355
Compare
|
Partly addresses #195 in that this helps setting the setupfile directly. But it seems there are remaining issues with the current gbasf2 releases that are not fixed by this and I don't have time to fix that right now. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Usage of
gbasf2_install_directorywill cause a pending deprecation warning,but it can still be used and then the corresponding path to
the
setup.shwill be derived.Rationale:
b2luigi only needs to know which file to source to get the correct
environment. The location or name of that file withing a gbasf2 install
directory can change between gbasf2 releases. Providing the file path directly
results in more simplicity and flexibility.
Additional enhancement:
In addition, the setting is now only obtained in the
Gbasf2Processclass andnot in the free helper functions, which now get the value via function
arguments. With this, the setting can be provided via a Task class attribute and
the value from the Task attribute will be used everywhere as expected.
This resulted in much more boiler plate code, but also it made my helper
function much more usable as library function without b2luigi settings.