Remove Python wrapper #35
Conversation
The Python version is basically not supported at this point (2) and having this adds a burden to developers and maintainers both alike. This can be added back later when the project is in a better state either directly or by a dependency or in another project altogether. Personally, it would be better maintained if added externally with other languages like Rust next to it.
|
@fzerorubigd I'll develop and merge my own master and make build breaking changes as well, abandoning GNU ways altogether. If there are any suggestions, I'll be glad to hear them. Thanks for the hard work as always... |
|
Hi Davoodeh,
Thanks for your comment. My intention for this project has been to keep it
in maintenance mode by addressing bugs and ensuring its stability.
If you're interested in developing a new library based on this project,
please feel free to do so. I would certainly support that endeavor.
However, the plan for this current project is to remain in maintenance mode
for the time being.
Thanks!
Forud
…On Thu, May 1, 2025, 2:51 PM M. Yas. Davoodeh ***@***.***> wrote:
*Davoodeh* left a comment (persiancal/jcal#35)
<#35 (comment)>
@fzerorubigd <https://github.com/fzerorubigd>
Since the development here is stale, I probably won't clutter this project
with my pull requests until further instructions from you (the sole
maintainer I suppose?)
I'll develop and merge my own master and make build breaking changes as
well, abandoning GNU ways altogether. If there are any suggestions, I'll be
glad to hear them.
Thanks for the hard work as always...
—
Reply to this email directly, view it on GitHub
<#35 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHEJ43AJ42U7I6GJO6UFEL24IKE5AVCNFSM6AAAAAB4HZGRQKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQNBUG44TEMJSHA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Thank you for your reply. I will close my pull requests, then. P.S: I suggest that you add this sidenote in the README. |
|
Hello again, I acted on your suggestion. After this while, I have a full implementation of a Jalali library, They are designed after the common I may also publish a demo of how I use As for adoption (#27), I ask of every participant to try my implementation and consider that instead. All contributions of any size are welcome. And if this try that I tried is worth it, we may be able to replace it with the current project. I make this proposition for the following reasons:
This probably marks my last contribution here. Again thanks for your wonderful suggestion @fzerorubigd |
|
Amazing, tho I have a suggestion on the name. This is not Jalali calendar,
but Persian calendar. Not sure why a newly created library goes with the
wrong name (again)
…On Wed, Oct 22, 2025, 7:08 AM M. Yas. Davoodeh ***@***.***> wrote:
*Davoodeh* left a comment (persiancal/jcal#35)
<#35 (comment)>
Hello again, I acted on your suggestion.
After this while, I have a full implementation of a Jalali library, jelal
<https://github.com/Davoodeh/jelal> written in Rust which supports of a
C, Python, JS and with more to come. Alongside two binaries built on top of
it as jcal-cal <https://github.com/Davoodeh/jcal> and jcal-date
<https://github.com/Davoodeh/jcal>, also written in Rust. Install with cargo
install jcal-date jcal-date.
They are designed after the common date and cal and the new
implementation solves all the open issues (#1
<#1>, #11
<#11>, #33
<#33>, #36
<#36> and #38
<#38>).
I may also publish a demo of how I use jelal
<https://github.com/Davoodeh/jelal> to simplify some parts of libjalali
(see updates on Davoodeh/jcal_c <https://github.com/Davoodeh/jcal_c>)
just for demonstration purposes.
As for adoption (#27 <#27>), I
ask of every participant to try my implementation and consider that
instead. All contributions of any size are welcome. And if this try that I
tried is worth it, we may be able to replace it with the current project. I
make this proposition for the following reasons:
- "the current project is in maintenance mode" and does not have much
of a pulse
- also, the current project has multiple stagnant issues since 2019
and difficulties with merging the PRs
Again thanks for your wonderful suggestion @fzerorubigd
<https://github.com/fzerorubigd>
—
Reply to this email directly, view it on GitHub
<#35 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHEJ4ZBI354NJXEP5EGV633Y4GNRAVCNFSM6AAAAAB4HZGRQKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTIMZQGUYTSNJQGI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
2 participants
The Python version is basically not supported at this point (2) and having this adds a burden to developers and maintainers both alike.
This can be added back later when the project is in a better state either directly or by a dependency or in another project altogether. Personally, it would be better maintained if added externally with other languages like Rust next to it.
"docs" and "man" are the next to go if you ask me. They are outdated docs and also a burden to maintain.