colin-b / keepachangelog Goto Github PK
View Code? Open in Web Editor NEWConvert keep a changelog markdown file into python dict
License: MIT License
Convert keep a changelog markdown file into python dict
License: MIT License
Right now it is fixed to the standard but it is not unusual for people to use various other categories
If a changelog entry ends with italics, eg:
### Changed
- Lorem ipsum dolor sit *amet*
Then the parsed entry would be:
"changed": [
"Lorem ipsum dolor sit *amet"
]
Which seems invalid to me.
A one-character change in _changelog.py
fixes this problem:
- line.strip(" -*")
+ line.lstrip(" -*")
I can do a PR too, but since this change is so quick, It'll be easier if @Colin-b can do it.
Right now this is not the case if additional information is provided as uncategorized.
Hello
We are using commitizen to write our commit definition, and often use scope to precise the subject of the commit.
During the release phase, we use commitizen bump to generate the changelog
At this instant, commitizen write the scope in bold:
We also use keepachangelog to extract some information from changelog of our module, but, during the .todict, the left scope ** are removed.
It's an expected behavior from add_information
function, but is it possible to authorize to have bold scope in a changelog?
If there is a specific reason to remove left star, is it possible to discuss to keep bold characters.
Thank you
Hi, I'd like to point out that switching "unreleased" casing breaks in facts retrocompatibility w/ previous versions, I'm maintaining a tool which manipulate changelogs and this breaks a lot of tests https://travis-ci.org/github/aogier/chachacha/jobs/767594962
Not a biggie, I will fix them, but I encourage you to reconsider your future versioning and adopt a proper semantic versioning
thanks and keep up the good work!
Ciao, I'd like to share a thought w/ you. Given the problem domain I think stripping the leading -
in category entries could be the right thing to do, you already assert an entry is an entry by placing it in relevant section after all.
That could be a future-proof evolution of the lib (eg. tomorrow KAC choose to use *
instead of -
) that could even keep it as a valuable resource should someone decide to implement a transcoding app.
And btw, I'm totally in a total rust reimplementation, getting faster speed by two order of magnitude. Do you like rust? I do like it, I'm still learning but so far so good!
ciao
Maybe an entry such as semantic_version
with a dict value containing major
, minor
, patch
and maybe some additional keys such as pre-release or metadata. I will have to dive a bit more into the semver doc to properly handle it as, for example, python does not uses -
but .
.
When not using entirely numeric version numbers (such as 2.1-PRELIM-03 or 1.3-FINAL-00), the text parts are transformed to lowercase after loading using to_dict (i.e. 2.1-prelim-03 or 1.3-final-00). This means additional logic is required to process them and compare the these with what I have in the other parts of my program.
Is there a reason for this that I have missed, or shall I create a PR to (optionally?) allow users to keep the case provided in the markdown file?
First, thanks to this parser. It looks promising and needed ;-)
For a given version, there is some properties already provided version
, release_date
.
It would be nice to add some more :
url
if described in the markdown file. For now, you need to parse again the file to find it in another script.is_pre_release
if the version name contains any pre release string : https://semver.org/Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
The last point can be easily detected by a third party script I agree, it's just to make it all in one ;-)
Ciao, this is just to let you know this project is now a dependency on my latest project chachacha, where I'm trying to implement a generic plugin-based changelog editing tool and other whistles that will come. Thank you for your work, ciao!
Pypi only appears to have packages for version 1.0.0. Do you intend on publishing v2.0.0 to pypi as well?
Hey Colin,
I started to use your project and I really like it. I think it would be very useful to add a to_str function in order to convert back a changelog dict to a string keeping the valid keepalog format.
The only prereq may be to start using OrderedDict in order to not loose the order of changes if adding/removing changes when updating the dict object.
Example:
import keepachangelog
changes = keepachangelog.to_dict("path/to/CHANGELOG.md")
## Add new changes here
changes.add(....)
with open("path/to/CHANGELOG.md", "w") as file:
file.write(keepachangelog.to_str(changes))
What do you think?
Etienne
As an option deactivated by default
Hey Colin!
Thanks for such a great project! I've been hunting for something like this over the last couple of days and was pleased to find this package.
I noticed that you (very reasonably) made the decision to only support non-pre-release semantic versioning but not to allow any pre-release information on the end of the version. I've got a project that is considered to be in beta, and although the changelog parsing works just fine, the changelog.release("CHANGELOG.md")
command errors out due to the most recent version having bXX
on the end of it which causes it to be considered an invalid version.
How would you feel about allowing pre-release matching and just bumping the pre-release number (e.g. b1
->b2
)? I do realize that this probably opens the door to a whole slew of cases, but perhaps we could systematically support more and just be explicit about what is and isn't handled. Then others can open issues as needed instead of trying to solve the whole scope of problems at once :)
Another option that doesn't quite solve the same issue but would perhaps at least be a good intermediate step would be to allow the passing of the desired version to the .release
function. If you don't like that because it allows people to abuse SemVer, I get that too.
Anyway, let me know what you think! I think this project is small enough that I could get familiarized with it somewhat quickly and contribute an attempt at this if you'd like.
Hi,
I'm aware, this request is not following exactly the convention https://keepachangelog.com/en/1.1.0/ but in some projects, there isn't some sub-sections like "Added", "Changed", "Deprecated".
Would it be OK to support this kind of file in this project or do you want to use only the convention ?
# CHANGELOG
## 0.5.0 - 2021-02-19
* A
* B
* C
## 0.4.0 - 2021-01-21
* D
* E
* F
Let me know what you think ?
I think in the function to_raw_dict
, there isn't any option to add the ## Unreleased
section.
It's possible in other function with show_unreleased=True
.
It's problematic when - for example - your pipeline has a pre-commit hook that checks for exactly 1 newline at EOF.
Reproduceable code:
import keepachangelog
clg_txt = """# Changelog
## [1.0.0] - 2022-10-18
### Added
- A cool feature
"""
with open('test.changelog.md', 'w') as f:
f.write(clg_txt)
clg = keepachangelog.to_dict('./test.changelog.md')
new_clg_txt = keepachangelog.from_dict(clg)
print(new_clg_txt.endswith('\n\n')) # True
Let's say I have the following changelog:
# Changelog
All notable changes to this project will be documented in this file.
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
## [Unreleased]
### Changed
- Changed `f()` and `g()` into `h(b:bool)`.
**The change is NOT backward compatible!!**
Please replace `.f()` -> `.h()`
And replace `.g()` -> `.h(b=True)`
Reason: There is a bug in `somelib` ...
More: https://bugs.python.org/issueXXXXX
- Release note 2.
## [1.0.0] - 2017-04-10
### Deprecated
- Known issue 1 (1.0.0)
- Known issue 2 (1.0.0)
[Unreleased]: https://github.test_url/test_project/compare/v1.0.0...HEAD
[1.0.0]: https://github.test_url/test_project/releases/tag/v1.0.0
Rendered as so:
All notable changes to this project will be documented in this file.
The format is based on Keep a Changelog,
and this project adheres to Semantic Versioning.
Changed f()
and g()
into h(b:bool)
.
The change is NOT backward compatible!!
Please replace .f()
-> .h()
And replace .g()
-> .h(b=True)
Reason: There is a bug in somelib
...
Release note 2.
If I run:
import keepachangelog
print(keepachangelog.from_dict(keepachangelog.to_dict('CHANGELOG.md', show_unreleased=True)))
This is what I get:
# Changelog
All notable changes to this project will be documented in this file.
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
## [Unreleased]
### Changed
- Changed `f()` and `g()` into `h(b:bool)`.
- The change is NOT backward compatible!!**
- Please replace `.f()` -> `.h()`
- And replace `.g()` -> `.h(b=True)`
- Reason: There is a bug in `somelib` ...
- More: https://bugs.python.org/issueXXXXX
- Release note 2.
## [1.0.0] - 2017-04-10
### Deprecated
- Known issue 1 (1.0.0)
- Known issue 2 (1.0.0)
[Unreleased]: https://github.test_url/test_project/compare/v1.0.0...HEAD
[1.0.0]: https://github.test_url/test_project/releases/tag/v1.0.0
Rendered as:
All notable changes to this project will be documented in this file.
The format is based on Keep a Changelog,
and this project adheres to Semantic Versioning.
f()
and g()
into h(b:bool)
..f()
-> .h()
.g()
-> .h(b=True)
somelib
...As we can see, each line is managed as a new note.
import keepachangelog, pprint
pprint.pprint(keepachangelog.to_dict('CHANGELOG.md', show_unreleased=True)['unreleased']['changed'])
['Changed `f()` and `g()` into `h(b:bool)`.',
'The change is NOT backward compatible!!**',
'Please replace `.f()` -> `.h()`',
'And replace `.g()` -> `.h(b=True)`',
'Reason: There is a bug in `somelib` ...',
'More: https://bugs.python.org/issueXXXXX',
'Release note 2.']
Basically what I'm after is the ability to use my own opening bit after # Changelog
instead of the standard one that Keep a Changelog provides.
Following the documentation :
https://github.com/Colin-b/keepachangelog#convert-changelog-to-dict
In Python, a dict is not ordered. So to use this API, another script needs to read all versions and re-ordered them according to semantic versioning to be sure about the order.
I think it would be nice to either change to a list, which is ordered and provided "indexing" for accessing members or switch to https://docs.python.org/3.7/library/collections.html?highlight=ordereddict#collections.OrderedDict ?
It would make it easier to fetch the latest version changelog like :
changes = keepachangelog.parse("path/to/CHANGELOG.md")
latest = changes[0] # Get the latest version described in the file
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.