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.

Sign up for GitHub

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

Jump to bottom

Fix automatic checks #187

Open
wants to merge 1 commit into
base: dev
Choose a base branch
from
Open

Fix automatic checks #187

wants to merge 1 commit into from

Conversation

gnn
Copy link
Collaborator

@gnn gnn commented Mar 29, 2021 •
edited
Loading

Fixes #183 by removing a module global function call and putting the corresponding logic into egon-data's startup function, using central configuration settings retrieval functionality and adjusting tests to previous changes.

@gnn gnn requested a review from ClaraBuettner March 29, 2021 18:40
@gnn gnn changed the title Fix automatic tests Fix automatic checks Mar 29, 2021
@gnn
Mark imports outside toplevel as intentional
a80bebe 
The comment above the imports explains why they are done at this
location. The `# noqa` comments tell any code checkers to skip these
lines.
@gnn gnn mentioned this pull request Mar 30, 2021
Closed
@gnn
Copy link
Collaborator Author

gnn commented Mar 31, 2021

I merged part of this PR into dev because @gplssm needed the fix. So for now, issue #183 is closed, but this PR remains open until @ClaraBuettner and @EvaWie confirm that #183 is indeed fixed.

ClaraBuettner
ClaraBuettner approved these changes Apr 8, 2021
View reviewed changes
Copy link
Contributor

@ClaraBuettner ClaraBuettner left a comment

Choose a reason for hiding this comment

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

Yes, as I commented in #183 , I tested it and everything worked fine.
But there is no note in the changelog about this.

@gnn
Copy link
Collaborator Author

gnn commented Apr 8, 2021

Yes, as I commented in #183 , I tested it and everything worked fine.

Cool. So that leaves the question of whether you, @EvaWie, are able to test your code again after the fix.

But there is no note in the changelog about this.

Maybe it's time for a release? Bug fixes usually only get noted in the changelog when they fix bugs appearing in a previous release. Bugs which appear during development of a particular release and are also fixed during the same development cycle usually don't get a note in the changelog because in theory, regular users never see the bug. In general, the changelog lists changes from one release to another.
So, since we've been developing the current version for a while now, maybe it's time to start adopting a biweekly or monthly release cycle to get a periodic feature freeze and bug status?

@ClaraBuettner
Copy link
Contributor

Maybe it's time for a release? Bug fixes usually only get noted in the changelog when they fix bugs appearing in a previous release. Bugs which appear during development of a particular release and are also fixed during the same development cycle usually don't get a note in the changelog because in theory, regular users never see the bug. In general, the changelog lists changes from one release to another.
So, since we've been developing the current version for a while now, maybe it's time to start adopting a biweekly or monthly release cycle to get a periodic feature freeze and bug status?

If we want to release on pypi and not only on github, I need to adjust one thing (the desaggregator installation), but I will do this soon. Besides that, I think there is nothing against a release.

@gplssm
Copy link
Contributor

gplssm commented Apr 12, 2021

Maybe it's time for a release? Bug fixes usually only get noted in the changelog when they fix bugs appearing in a previous release. Bugs which appear during development of a particular release and are also fixed during the same development cycle usually don't get a note in the changelog because in theory, regular users never see the bug. In general, the changelog lists changes from one release to another.
So, since we've been developing the current version for a while now, maybe it's time to start adopting a biweekly or monthly release cycle to get a periodic feature freeze and bug status?

If we want to release on pypi and not only on github, I need to adjust one thing (the desaggregator installation), but I will do this soon. Besides that, I think there is nothing against a release.

Releasing is a bit ambiguous. I can refer to create a release on GitHub (via git tags) or to publishing a package on pypi. Maybe it helps to distinguish these two.

From my point of view, it is helpful to create a GitHub release (aka a version tag of eGon-data) in order to get a better overview on fixed bugs and changes in general. We could do this very soon, if someone is interested in doing it ;-)

Publishing the package on pypi makes sense, once we can provide useful data for at least one model that uses eGon-data generated data (eTraGo, ding0, ..).

This means, no hurry @ClaraBuettner with doing the changes. Unless you're done with the eTraGo input data.

@EvaWie
Copy link
Contributor

EvaWie commented Apr 15, 2021

Cool. So that leaves the question of whether you, @EvaWie, are able to test your code again after the fix.

Thanks for solving this issue! I can now test my code parts, also when airflow is not running.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@ClaraBuettner ClaraBuettner ClaraBuettner approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

GitHub actions fail
4 participants
@gnn @ClaraBuettner @gplssm @EvaWie