-
Notifications
You must be signed in to change notification settings - Fork 122
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
Interactive create #482
Interactive create #482
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## trunk #482 +/- ##
===========================================
+ Coverage 99.84% 100.00% +0.15%
===========================================
Files 13 13
Lines 631 654 +23
Branches 146 156 +10
===========================================
+ Hits 630 654 +24
+ Partials 1 0 -1 ☔ View full report in Codecov by Sentry. |
Thanks Chris for this nice PR. At a first review, my initial comment was to move the configuration changes into a separate PR and focus this PR only on the interactive part. But I am also ok to review this together. It's just that it will take more time to review. Thanks again for your help. |
Yes, I threw in a bit more than I should have... but it was all intertwined and it was too messy to provide them as individual PRs. If any area becomes contentious, I'm happy to remove it from this PR. Preemptively defending the secondary changes:
|
Thanks. I will try to take a look at this next week. |
e97b3e2
to
c742497
Compare
Sorry Chris for this late review. If you are still interested in this. I think that as long as the tests are green, this can be merged. I don't know whey I will have time to test this. |
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 review. and many thanks for the PR. it was easy to follow.
I did a quick code review.
I didn't had time to get the code and run manual tests.
Please see my inline comments and let me know if they make sense.
I think the changes are ok, but it's important to have better release notes for the changes here.
it looks like besides interactive create, this PR also adds 2 new features and breaks at least 1 backward compatibility :)
We can merge this as it is, as long as we document the changes as part of the release notes.
def _main( | ||
ctx: click.Context, | ||
directory: str | None, | ||
config: str | None, | ||
filename: str, | ||
edit: bool, | ||
edit: bool | None, |
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.
Why not leave edit
as always being boolean ?
It looks like we are using None
here as a placeholder for the default value.
But maybe it's better to have the explicit default value defined in this way.
edit: bool | None, | |
edit: bool = True, |
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.
This is only set to True
only if the content is still the default content. If a user specifies their own content then, we don't want to default to triggering editing mode. But by leaving it None
, it makes it possible to provide custom content and still explicitly choose to enable editing mode with this flag.
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.
We can have it like this... it looks like we are hijacking this variable :)
We should have a separate flag to signal the other use case.
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's the same behaviour as any of the other cli settings that also have a configuration setting. If None, fall back to the configuration, otherwise use the value as provided.
additional_args=["-c", content_line, "--no-eof-newline"], | ||
eof_newline=False, | ||
) | ||
|
||
def test_message_and_edit(self): | ||
""" | ||
When creating a new message, a initial content can be passed via | ||
the command line and continue modifying the content by invoking the | ||
text editor. |
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.
Maybe add a comment that the conten is pass verbatim
and no extra newline or processed is done.
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.
Because that comment would be incorrect. The newline option is still processed after it's received back from the editor.
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.
This is specifically testing the case mentioned elsewhere when a user provides custom content but still chooses to edit their content first.
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.
OMG :) Are people using this feature ?
I am ok with that, we can have it.
It looks so complicated :) ... but I have never felt the need for towncrier create
For me it's always easier to just create the file directly in my text editor, without calling towncrier.
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.
I don't have much time for this reaview...and I don't really understand the need for towncrier create
... in general :)
So, I am not the best person to review this.
But we should try go get this merged.
As long as it has docs + tests, it should be ok.
My comments are about:
- backward compatibilty , related to the default values of the new config options
- adding yet another CLI argument to
towncrier create
... maybe having the value in config file is enough
I hope @hynek or @altendky can take a look and see if we need the extra CLI argument and it it's ok to introduce this backward compatiblity change.
Thanks again
I am using a towncrier version from 2017 ...and I am happy with that. So I don't really care.
I am just trying to maintain this, as part of my release management work for twisted/twisted
def _main( | ||
ctx: click.Context, | ||
directory: str | None, | ||
config: str | None, | ||
filename: str, | ||
edit: bool, | ||
edit: bool | None, |
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.
We can have it like this... it looks like we are hijacking this variable :)
We should have a separate flag to signal the other use case.
@@ -52,6 +52,8 @@ class Config: | |||
wrap: bool = False | |||
all_bullets: bool = True | |||
orphan_prefix: str = "+" | |||
create_eof_newline: bool = True | |||
create_add_extension: bool = True |
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.
Should these 2 new config options have the default set to False, for backward compatibility ?
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 depends if backwards compatibility is more important than (imo) more sensible defaults. I'll leave that decision to the maintainers to make a call on.
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 using the create command... so I don't know what to say.
In general, the rule is to keep backward compatibiliy. Any exception should be explicitly raised and accepted on a case by case basis.
We don't have a separate backward compatiblity policy for towncrier ... so I go with the general Twisted org policy https://docs.twisted.org/en/stable/development/compatibility-policy.html
I am happy to have a separate policy for towncrier.
Since towncrie is a dev tool, I think we can be more releaxed.
At the same time, I don't like when a CI pipeline breaks after an update
I guess that towncrier create
is not used as part of any automation... so we should be ok.
If nobody else is -1 on this default, I will merge is at it is.
I am happy with the new defaults.
Thanks!
additional_args=["-c", content_line, "--no-eof-newline"], | ||
eof_newline=False, | ||
) | ||
|
||
def test_message_and_edit(self): | ||
""" | ||
When creating a new message, a initial content can be passed via | ||
the command line and continue modifying the content by invoking the | ||
text editor. |
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.
OMG :) Are people using this feature ?
I am ok with that, we can have it.
It looks so complicated :) ... but I have never felt the need for towncrier create
For me it's always easier to just create the file directly in my text editor, without calling towncrier.
|
||
Now by default, when creating a fragment it will be appended with the ``filename`` option's extension (unless an extension is explicitly provided). For example, ``towncrier create 123.feature`` will create ``news/123.feature.rst``. This can be changed in configuration file by setting `add_extension = false`. | ||
|
||
A new line is now added by default to the end of the fragment contents. This can be reverted in the configuration file by setting `add_newline = false` or explicitly set with the ``create`` command line flags ``--eof-newline/--no-eof-newline``. |
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 ok with this new default value... but maybe it should be placed into a separate section ... as it looks like a backward incompatible change.
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.
As in a separate fragment? I'm not sure where else you mean this should go.
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.
Usualy backward incopatible changes are announced into 482.removal.rst
This is the "Deprecation and removal" category.
I know that "removal" is a bad name... but this is what we have.
There are a log of bad defaults and bad naming conventions in towncrier :(
bad as in non intuitive
@@ -0,0 +1,5 @@ | |||
If no filename is given when doing ``towncrier`` create, interactively ask for the issue number and fragment type (and then launch an interactive editor for the fragment content). | |||
|
|||
Now by default, when creating a fragment it will be appended with the ``filename`` option's extension (unless an extension is explicitly provided). For example, ``towncrier create 123.feature`` will create ``news/123.feature.rst``. This can be changed in configuration file by setting `add_extension = 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.
Not sure if this is feature, or a backward compatiblity break :)
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's a change in the filename but since the file is parsed by towncrier in exactly the same way, I don't think it's really backwards incompatible
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.
OK. Thanks. Fine by me.
I am not sure that adding release notes in this way, in a single fragment, does what we want.
I remember that towncrier will create one list item per file
On my project, as a hack I have 482-1.feature.rst
as a way to add another item in the notes...but I think that we need better support here
I remember there were other disussions about this
…ig option is enough.
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.
All good.
The only think blocking this is moving the backward incomaptible change into a .removal
fragment
I will wait a bit to see if anyone else has anything agains this backward incopatible change and all is ok, this can be merged.
thanks again!
@SmileyChris I think that you are already in the top 5 contributors of this repo for the last few years, so I consider you one of the de-facto maintainers I sent you an invite to a team that has write access to the repo. |
I found a bit of time today, so I have triggered the auto-merge. I am not sure when I will have time to check this. If anyone is -1 on these changes, we can still revert them before the next public release. Thanks for all your help! |
Description
If no filename is given when doing
towncrier create
, interactively ask for the issue number and fragment type (and then launch an interactive editor for the newsfragment content).Reworded interactive edit comment
The comment given to the editor has been reworded to use the similar format as a git commit interactive edit, with the empty space above rather than below:
Default news fragment filename extension
If the file extension of the
filename
configuration setting ends in.rst
or.md
,towncrier create
will append this extension to newsfragments it creates (if the filename didn't provide an explicit extension).This is configurable with a new
create_add_extension
setting (true
by default).Add an empty line to the end of news fragments
An empty line is now added to the end of news fragment content, whether entered by the command line option or interactively.
This is configurable with a new
create_eof_newline
setting (true
by default).Checklist
src/towncrier/newsfragments/
. Describe yourchange and include important information. Your change will be included in the public release notes.
docs/tutorial.rst
is still up-to-date.docs/cli.rst
reflects those changes.docs/configuration.rst
reflects those changes.