-
Notifications
You must be signed in to change notification settings - Fork 123
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
Use common code between draft and not for combining top line and rendered #303
Use common code between draft and not for combining top line and rendered #303
Conversation
Codecov Report
@@ Coverage Diff @@
## master #303 +/- ##
==========================================
+ Coverage 97.04% 97.08% +0.03%
==========================================
Files 22 22
Lines 1321 1339 +18
Branches 126 128 +2
==========================================
+ Hits 1282 1300 +18
Misses 20 20
Partials 19 19
Continue to review full report at Codecov.
|
I can confirm this fixes the issue. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good.
I would say that top_line
should be moved outside of `append_to_newsfile.
Also, what is single_file
in the context of append_to_newsfile
? :)
If single_file is False it will make existing_content a list and compare it with top_line
Doesn't look ok :)
My suggestion is to extract the duplicate version detection code outside of append_to_newsfile
. Have a dedicated name for this method and add all the checks there :)
src/towncrier/test/test_build.py
Outdated
[ | ||
"--version", | ||
"7.8.9", | ||
"--name", | ||
"foo", | ||
"--date", | ||
"01-01-2001", | ||
"--draft", | ||
], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a bit easier to read :)
[ | |
"--version", | |
"7.8.9", | |
"--name", | |
"foo", | |
"--date", | |
"01-01-2001", | |
"--draft", | |
], | |
[ | |
"--version=7.8.9", | |
"--name=foo", | |
"--date=21-01-2001", | |
"--draft", | |
], |
Perhaps I am misreading this, but isn't that what I did here? Are you confirming that is good, or suggesting something else should happen?
I think single file is the standard usage where towncrier tries to inject new news into the right place in an existing file (generally) where as not-single-file is if you make a separate output file each time you process news fragments. Maybe this is more common in bigger projects where you might have a large output file for each release and then if you want a comprehensive all-history output you could join each individual release file together. Maybe? So, if it is not a single file, you don't need to do all the reading of the existing content and injecting of new content, just write the new content over anything that may or may not be there. I'm not super excited about this code design, but I think it works? Well, other than the fix over at #301 (comment) which you made me rethink the fix for (and I already rethought again...).
What version detection code is there in |
I was suggesting this removal :) - def append_to_newsfile( directory, filename, start_line, top_line, content, single_file=True
+ def append_to_newsfile( directory, filename, start_line, content, single_file=True |
This is the code in which if single_file:
if not os.path.exists(news_file):
existing_content = u""
else:
with io.open(news_file, "r", encoding="utf8") as f:
existing_content = f.read()
existing_content = existing_content.split(start_line, 1)
else:
existing_content = [u""]
if top_line and top_line in existing_content:
raise ValueError("It seems you've already produced newsfiles for this version?") |
The catchup merge brought in some problems. I reworked it a bit. I didn't get Sorry, but I feel like this is enough of a change to deserve a re-review. I'm also not convinced this is a well focused PR, so 'go break this down into more pieces' is a perfectly reasonable response. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the update.
Just a comment for now... but I am kind of -1 or the PR as it is now.
I am confused by the tests :)
============================================== | ||
{% for section in sections %} | ||
{% set underline = "-" %} | ||
{% for category, val in definitions.items() if category in sections[section] %} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it looks like all these jinja directives from the template are not used in this test.
I don't understand why you would like to have title_format = false
and a custom template.
With a custom template you can just don't include the title part without having to use False.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this template should be able to have all these normal template bits removed. Change incoming.
Does it matter why you would want that scenario if it is documented and released functionality? Or is this question more about making sure we have a common understanding of the feature than questioning if the situation should be tested? I haven't really thought through what I think the configuration design ought to be as I'm targeting a bugfix+feature release without introducing breaking changes (nor deprecations).
None the less, false is exactly for the case where you specify a template that provides its own title. If you don't specify false then you will (should? i think?... :[
) get the default title before whatever your template does. I do feel funny about the existing non-empty string or empty string/unspecified or false possibilities for title_format
. I guess I see the use cases along the lines of 'default title format and template' (unspecified or empty string), 'the default template is fine but i want to change just the title format' (non-empty string), and 'gosh darn it let me just write everything in my custom template' (false).
Hopefully this helps... this is definitely an area that strikes me as simply confusing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it matter why you would want that scenario if it is documented and released functionality? Or is this question more about making sure we have a common understanding of the feature than questioning if the situation should be tested?
It's more about understanding the feature and its valid use cases.
I imagine someone reading this test 1 year in the future, looking at a bug and will say: Why you need this feature with a custom template.
So I prefer to have a test in which the feature is tested like in real file, and not using a combination of configuration option that are possible, but will never be used.
At the same time, I think that this test is wrong. We should have a full test for the default template itself.
This should also be a test for the {% if render_title %}
part of the default template
|
||
def test_with_topline_and_template_and_draft(self): | ||
""" | ||
Spacing is proper when drafting with a topline and a template. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure what the difference between test_title_format_custom
and this test.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It at least differs in that this specifies a custom template while test_title_format_custom
leaves the default template in use. When writing this test it ended up a bit confusing to me too how all the bits were interacting but it did seem to recreate the issue reported at #105.
I feel like the existing implementation code had evolved and needed cleanup but as it was it offered corners where specifying a title format _with_ a custom template _and_ draft (and maybe something about the title-less feature section?) could result in some unique bug.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Understood. But I think that this test can be removed.
Now that we use the exact same output for draft and final,#105 should be fixed.
I would prefer not to have this tests as it's long and confusing.
The test only checks the output of draft.
A good test for #105 would had generated the output with and without draft and compare them to make sure they are exactly the same.
But I don't think that we need extra test for that.
I made sufficient changes that a re-review is needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me know if the explanation of the tests helps, or maybe it just reinforces the -1. I could understand that. The issue reported in #105, as I recall, was a weird corner case and perhaps I should approach it with a differently formed PR.
|
||
def test_with_topline_and_template_and_draft(self): | ||
""" | ||
Spacing is proper when drafting with a topline and a template. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It at least differs in that this specifies a custom template while test_title_format_custom
leaves the default template in use. When writing this test it ended up a bit confusing to me too how all the bits were interacting but it did seem to recreate the issue reported at #105.
I feel like the existing implementation code had evolved and needed cleanup but as it was it offered corners where specifying a title format _with_ a custom template _and_ draft (and maybe something about the title-less feature section?) could result in some unique bug.
============================================== | ||
{% for section in sections %} | ||
{% set underline = "-" %} | ||
{% for category, val in definitions.items() if category in sections[section] %} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this template should be able to have all these normal template bits removed. Change incoming.
Does it matter why you would want that scenario if it is documented and released functionality? Or is this question more about making sure we have a common understanding of the feature than questioning if the situation should be tested? I haven't really thought through what I think the configuration design ought to be as I'm targeting a bugfix+feature release without introducing breaking changes (nor deprecations).
None the less, false is exactly for the case where you specify a template that provides its own title. If you don't specify false then you will (should? i think?... :[
) get the default title before whatever your template does. I do feel funny about the existing non-empty string or empty string/unspecified or false possibilities for title_format
. I guess I see the use cases along the lines of 'default title format and template' (unspecified or empty string), 'the default template is fine but i want to change just the title format' (non-empty string), and 'gosh darn it let me just write everything in my custom template' (false).
Hopefully this helps... this is definitely an area that strikes me as simply confusing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the late reply.
My changes for this :
test_title_format_false
should use the default template, to cover the logic from default template.
============================================== | ||
{% for section in sections %} | ||
{% set underline = "-" %} | ||
{% for category, val in definitions.items() if category in sections[section] %} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it matter why you would want that scenario if it is documented and released functionality? Or is this question more about making sure we have a common understanding of the feature than questioning if the situation should be tested?
It's more about understanding the feature and its valid use cases.
I imagine someone reading this test 1 year in the future, looking at a bug and will say: Why you need this feature with a custom template.
So I prefer to have a test in which the feature is tested like in real file, and not using a combination of configuration option that are possible, but will never be used.
At the same time, I think that this test is wrong. We should have a full test for the default template itself.
This should also be a test for the {% if render_title %}
part of the default template
|
||
def test_with_topline_and_template_and_draft(self): | ||
""" | ||
Spacing is proper when drafting with a topline and a template. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Understood. But I think that this test can be removed.
Now that we use the exact same output for draft and final,#105 should be fixed.
I would prefer not to have this tests as it's long and confusing.
The test only checks the output of draft.
A good test for #105 would had generated the output with and without draft and compare them to make sure they are exactly the same.
But I don't think that we need extra test for that.
Co-authored-by: Sviatoslav Sydorenko <[email protected]>
@altendky @adiroiban Is this PR still alive? I have lost the plot on the controversy over this change, and I'm not sure how to review it taking that history into account. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having this blocked was my fault for commenting to much in terms of automated tests.
The tests are very verbose and might break with future changes that are not related to the draft functionality.
And there was no other towncrier developer to step in and approve it.
Since we have limited resources for towncrier development, let's merge this as the issue if fixed.
We can worry about code cleanup and reducing the test side-effects later :)
Thanks @glyph for the follow up. |
@altendky @adiroiban any chance to release this soonish? AFAIK, this fixes poor UX in https://github.com/sphinx-contrib/sphinxcontrib-towncrier that's been annoying since about v21. |
Fixes #105.