Open Lakr233 opened 2 years ago
Hi @Lakr233,
This is very interesting! I will have a closer look at the implementation and merging it when I have more time, but I have two questions nevertheless.
My current plan is to move away in the future from the "algorithm"-specific error types, such as TarError, DeflateError, etc. As part of this plan all new additions use a more general error type, DataError
. I've noticed that you add a new error type ArError
, so my question: is it possible to use instead DataError
?
With regards to this issue:
The reason not opening a pull request is that we have noticed you are submoduling a git repo for test files and your pipeline seems to be a little heavy for configurations. During our development, we simplified these process and we make all our AR file test work locally.
What did you find particularly complicated about my setup/pipeline? I genuinely curious about this, maybe there is something I can do to simplify it in the future.
I've noticed that you add a new error type ArError, so my question: is it possible to use instead DataError? yes
What did you find particularly complicated about my setup/pipeline? The main reason is that we do not have permission to access your submodule repo and to avoid road blocks in development. Don't feel like to make changes to your workflow.
Hi again,
I've been thinking about this and I don't think I can accept these changes without an actual pull request.
The problem is that as it currently stands what you're essentially asking me here is to copy someone else's code (the repository that you've linked here belongs to a different user, not to you) without their express permission.
With the PR from the author I will be assured that:
I’m the collaborator of that repo. I have add a notice there in the README to authorize this action. It’s a little bit complicated to explain why not a PR but it should explain the right for you to do so. The author is my friend and we work together for many.
The original code license(I see you did with MIT License) could be applied.
Would love to see the support for AR
. What's holding this back?
@mickeyl
Well, my concerns with accepting the contribution discussed in this issue have never been addressed.
At the same time, I do not see adding support for AR as a high priority for this project, and unfortunately I do not have enough time even for higher priority stuff. So as I result, I have never got around to implementing AR by myself.
I dont understand what you stated as "never been addressed".
We have implemented support for BSD AR file format at: https://github.com/Lessica/SWCompression/tree/feature-bsd-ar
The reason not opening a pull request is that we have noticed you are submoduling a git repo for test files and your pipeline seems to be a little heavy for configurations. During our development, we simplified these process and we make all our AR file test work locally.
We would like yourself to merge the codes if you are ok with it. Estimated more than one repo are required to update for this merge.
The package structure are a little different from the upstream, follow are the changes we made.
Are the sources for AR API interface, supports reading and writing.
Is a extension for ourself.
Is a bug fix for Apple stuff returning mismatch item from their document. If a nil is returned, do not throw an error.
Are tests we made.
With above changes applied to, we can make another check in README~
Have a nice day~