Closed igneus closed 4 years ago
Just a small proposal, maybe not even a feature but rather a bugfix: calendariumrom query
outputs the season as a Ruby object, which is not very human readable:
$ calendariumrom query [16:17:32]
2017-10-03
season: #<CalendariumRomanum::Season:0x000055e8fd0d3d60>
ferial : Tuesday, 26th week in Ordinary Time
Is this the desired behaviour, or should this be fixed?
If desired, i think i can fix this. However, since it's Hacktoberfest and i am new to all the collaborative features in git and github (just used it for myself until now), i'd like to ask: What is the usual workflow from now on? I have branched my local copy, pushed the changes in the branch to my fork and created a pull request. Until you haven't merge this pull request, i would now:
Is this the correct workflow? But what, if i, for example, need a work from a previously committed and pull-requested, but not yet upstream merged branch for a new-feature branch? Should i just branch from the first branch instead of the master? Will git correctly merge it, if i have several dependent branches, and, e.g. branch A is branched from master, and branch B is branched from A, and i merge B into master, but not A?
Hi @simonszu , the output is not intended. It's a bug introduced as a side effect of https://github.com/igneus/calendarium-romanum/commit/9e33ca478416ec287f7d402151e1bddb44f22076 Fix will be most welcome.
The workflow you propose is almost correct. Just instead of 4 you should pull from the upstream repository (add it as a new remote repo to your local clone).
But what, if i, for example, need a work from a previously committed and pull-requested, but not yet upstream merged branch for a new-feature branch? Should i just branch from the first branch instead of the master?
Then you could base a new branch on the previously "pull-requested" one and make a notice in the subsequent PR's description "based on previous pull-request #N". There's an inherent danger (danger of your work going in vain) in this scenario: if the first PR doesn't get merged for whatever reason, the subsequent one won't be merged either, or I will ask you to perform some rebasing or cherry-picking gymnastics in order to submit only a subset of the changes, without the unwanted ones.
Hey, @igneus I have worked out an ability to specify a custom calendar file to load from file system. I need your suggestions for writing tests for this.
I'd like to add a file with an invalid calendar format for the test. The test should test the cli command to fail when loading this invalid data file. But where should i save this file? Is it okay to create a directory spec/data
and store this file therein?
For testing the loading of a valid file from the file system i can use the filesystem path to a builtin calendar, i think.
@simonszu
Is it okay to create a directory spec/data and store this file therein?
As the example file will be tiny, it's preferable to use aruba's write_file
helper and have complete contents of the file directly in cli_spec.rb
. I have used this approach when writing specs for the errors
and cmp
subcommands.
For testing the loading of a valid file from the file system i can use the filesystem path to a builtin calendar, i think.
Sure.
Closing. It is not planned to add any substantial new features to calendariumrom query
.
EDIT October 2019: no more significant features are planned for the
calendariumrom query
subcommand - bug fixes are still most welcome, but a new, feature-rich CLI for calendarium-romanum is being developed as a separate gem https://github.com/calendarium-romanum/calrom. Feature requests and/or contributions should be directed there.The gem ships an executable
calendariumrom
, whose functionality is defined in class CalendariumRomanum::CLI.Subcommand
query
enables the user to query liturgical calendar from the commandline. This subcommand could be extended and improved:cli_spec.rb
)calendariumrom query 2017-10
), print records for the whole monthcalendariiumrom query 2017
), print the whole yearls
orgit
)~Separate PRs are preferred over a huge one implementing all or several of the suggested features. Proposals of other features are most welcome.