-
Notifications
You must be signed in to change notification settings - Fork 43
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
Make it possible to configure clog via .clog file #20
Comments
What about have two types of configs? Like a system-wide one to set some basic defaults under |
Not that there's a massive list of options right now to justify having a system wide config file, but I was thinking ahead in case there's a lot more options in the future (like I have some ideas for too). |
This would probably be pretty simple with something like toml-rs |
I'd say a system wide config is nice to have and I wouldn't vote against it. But as you say, we don't have a massive list of parameters (yet) so a local one is what I care about at the moment. Regarding the naming, I'm also fine with |
Cool, I think local is just fine for now. :) And I agree with Kevin about using toml, but at the same time I don't really mind whatever the format either. |
Ok, cool. Anyone feels like working on that? |
I would! But I can't! :( Sorry I can only help with comments for now. If I can make time, hopefully sometime soon, I will give a go at actual contributions, because I do have a few ideas on how to improve clog a bit. But unfortunately no time to focus on this right now. I know the codebase is very small (for now), but I still consider myself a newbie with rust itself, which I want to fix first. |
No worries, and yep the code base is very small and more or less a direct port from JavaScript to Rust. So it's a good code base to learn Rust ;) |
I may have some time this weekend to play around with it, but no promises :P I don't want to stop anyone else from working the issue. If I make it to a usable or close state I'll put in a PR. |
sounds good 👍 |
I started to play with this again today (A little later than the weekend...sorry :P) using toml-rs, but I ran into some moral (?) issues. If you specify a So I started with a toml file like so
Then I started thinking, "why have a toml file with just these two entries?" You cold just make On a different off topic note, I started using |
Yeah I was thinking about this. If understand what you meant, why not just grab this information from the Also, scrap the |
Great finding @kbknapp! I agree that we could just use sensible defaults for I'd agree with @vyp that we should pick the The only problem I see is that we probably need to do some parsing/processing with the string that we get from the For instance mine currently points to |
Super cool, that you started using it for I'd really like to spread the usage even more. It would be super cool if we can get it distributed via package managers such as homebrew. Also having windows binaries is on my wishlist but unfortunately cross compiling isn't one of Rusts strength so far :/ |
True, hadn't thought of that. If it gets too complicated, you could take the simple route and promote the usage of parameters/config file instead of trying to support every case. Is the repository parameter only used for the links in the changelog, or is it used for other things too? |
@cburgdorf Although I haven't done it before, I could look at submitting an Arch AUR package for For Mac,I have a MacBook that I [almost] never use, so I'm not too familiar with homebrew. Not to derail too much, as this could go in #12 but as for Windows...that's a whole other beast. I've got some windows machines, so compiling a binary shouldn't be too difficult, but the package management system there is super foreign to me (chocolatey?). |
@vyp awesome! I would imagine a Edit: which I guess isn't any different from having a |
Cool, submitted an AUR package for arch linux: https://aur.archlinux.org/packages/clog-git/. |
Super cool! Does it mean it's available on arch linux from now on or does it need to go through some review/whatever process first? |
@kbknapp For some reason, I didn't see your comment before I submitted the package (it didn't show up), all I've done is named it
It does! However, it does NOT go through any review process. I think I should expand here just to clarify about a bit of how Arch linux in particular works (this does not necessarily apply to other linux systems). Arch has 'official' repositories. If you've ever used linux, this is your usual official repositories where you'd expect to find a lot of the basic and popular FOSS software (e.g. system utilities, libreoffice etc.). However, Arch linux does not have that many developers/manpower, so supporting every package ever made (and made available on the internet as open source software), is out of the question. I think the only distribution which could even challenge to do that is Debian, but I'm not sure. So what Arch did to help this issue of a lot of software not being available (through official channels) is create the 'Arch User Repository', in short 'AUR'. Basically, ANYONE can upload a 'package' here, and then Arch users can then download these 'packages' and the 'package' can be used straight away (as long as the 'package' is created properly). They DO NOT go through any review process. What this of course means is, the 'package' can easily be malicious or disingenous, since ANYONE can submit it, not necessarily the creator of the original software itself. However, I quote 'package' here because it is not a package that is being uploaded in the normal sense of the word (i.e. it's not the So by 'submit', all I really mean is upload to this user-controlled repository which has no oversight. (The arch project strongly discourages using many AUR packages because of this.) There is no review process. However, very popular AUR packages do have a chance to eventually land up in official channels, where of course they will be reviewed and everything. Ugh, sorry for so many words. I just thought it'd help to explain this because it is your software that is ultimately being made more easily available on a platform, but without your knowledge of how it really works, i.e. whether you can endorse (by linking to it) or not. |
Thanks for the great writeup. Looking at the receipt it seems it will always install the latest version right? |
I'm by no means an expert on this, but to be more specific, what would happen (in essence) is I would download this PKGBUILD. Run a command called There's three main sections to my pkgbuild, the metadata, the build() function, and the package() function. The metadata is obvious, at the start. The build function is what The package function simply means the (binary) file at To answer the question, yes, because it is a git package. I'm not 100% sure, but if the source specifies a |
BTW, if you do endorse this AUR package, you should make it clear that you yourself did not create, nor do you maintain it, so use at your own risk etc. Because for example, I could (in theory) simply update the PKGBUILD to be malicious. Or what if my account gets comprimised by a malicious actor? etc. etc. |
@vyp well, yes but they could also compromise my account. And hey I trust you because, we are both just random persons on the internet :))) |
I think I'm going to re-address this soon to add something like what's mentioned in #3 Once #27 is merged, it'll be easier to add some of those settings. The initial implementation I'm thinking will allow for specifying the repo, and any custom aliases. Perhaps a future addition would be allowing specification of custom sections as well. For example, right now we break out Features and Fixes, everything else gets ignored. This would allow a user to add a custom section that gets picked up into their changelog, and their own aliases for that section. I'm thinking something like: [sections]
Feature = [ "feat", "ft"]
Fix = ["fix", "fx"]
Performance = ["perf", "pf"]
# used in commit subjects like
# myalias(component): my message
# or
# ma(component): my message
MySection = ["myalias", "ma"] etc. But again, this I think will be a future addition, for now let me just get the repo and custom aliases working :) |
👍 I think that's a great idea. About the myalias, I'm also in favour of it (via the .clog file), because if the user wants to use that, then more power to them right? However, a reason to not have that is that this starts (slightly) going away from the "conventional changelog standard" which angular.js sets out (did they 'invent' it?). Again, I'm for it, but @cburgdorf might have different opinion... |
Good point. What I'd suggest then is that there is always at least the "conventional" sections. This would just allow users to add to, but not take away from them. So they could add their own aliases to the conventional sections, and add their own sections as well but not take away the conventional ones. Just a thought. |
What happens if one of the aliases for MySection = ["feat", "ft"] I'm assuming that |
That'd be pretty easy to guard against, or detect. I'll wait for @cburgdorf guidance on if he'd rather exit with an error (i.e. no overriding or duplicate alias/sections), or let the user override a default with their own custom section/alias. |
Basic implementation of this is done. See #27 for details, but the quick and dirty is it looks for a |
Sounds like a really good plan. 👍 Regarding
I'm personally ok with |
Awesome! 👍 |
Since the initial implementation of this is done. I'll call this closed (with 0d27d2f). It'll be easier to track new additions, or changes with individual issues. I'll create a |
This would allow to set a given set of options (
--repository
,--from-latest-tag
)The text was updated successfully, but these errors were encountered: