Open ickc opened 4 years ago
I'm not really sure what to do about this library. I currently don't have time to maintain it, but I'm happy to spend some time for a proper handover if we can find a new owner for the code. (I spun this off a StackOverflow answe and never meant to really maintain it, but it unexpectedly became somewhat popular.)
@sylikc Would you like to become the "official" owner of the code? Would anyone else like?
Things we should do to hand this over:
There’s also a way to transfer in GitHub to make his “official” and others forks of his. I forgot exactly how but it can be done.
I made 3 PR to @sylikc ~11 days ago. But there's no activity there. Looking at @sylikc/pyexiftool I found that all the new commits happened in July 2019 so I'm not sure if he's still actively maintaining that.
I recently wrote a tool (so far for personal use only) that depends on pyexiftool. It is very likely that I'll continue to use my tool and hence continue to improve pyexiftool since there's seem no other better way (my tool needs to know the metadata from raw so exiftool is uniquely capable on that.) And unless I move to another language or write my own code to basically does what pyexiftool does then I should be able to continue to maintain that.
And I currently maintained a few packages on PyPI so it is likely I can continue to keep the packages up-to-date in PyPI including CI on newer versions of Python. (I might add a conda package for it too since for conda environment it is more convenient.)
I think if @sylikc wants to, since he has longer history on using that tool and already done a dozen merges on the PRs here, he should be the first choice. But if we don't hear from him soon we may interpret that he's not actively maintaining that either. Then I'm willing to pick it up.
I am happy to maintain this. When I have free time, I'm actively developing my own scripts to accelerate my photography workflow. I have an internal gitlab so haven't been as active checking GitHub thinking no one would use it :)
Thanks for the enhancements @ickc and thanks for making the code available and doing all the initial legwork @smarnach
I'm aware one of the forks in some way or form is in PyPI which of course is many versions behind what PR I've merged from this project.
I don't have the experience with PyPI, but I'd be willing to learn from you @ickc how to get the package up, and maintain it.
Sounds like a plan. If @smarnach agree then may be @smarnach could transfer the ownership of GitHub to @sylikc first?
About PyPI, currently on PyPI PyExifTool is owned by intense.feel/Martin Carnogursky in https://pypi.org/user/intense.feel/. Do you know his GitHub username? If we can't contact him then we could just have it in an alternative name (not uncommon when they have multiple forks.)
That's me on PyPI, I was going to upload the forked & modified version but forgot to change the package name before uploading so I took the package name by accident. Please let me know the PyPI name of the new maintainer and with a confirmation from @smarnach I will transfer the ownership of the package on PyPI.
I created an account on PyPI to prepare for a transfer. same username.
@sylikc @RootLUG Thanks a lot, sounds all good to me. It will take me a few days until I can find time to update links etc, but I will eventually get there.
cool @smarnach how do I set up the githubio page for the documentation? is there an automated process to generate the docs?
Sorry about the delay! This is still on my list, but I'm really busy at the moment. :-/
Is there any update on this @smarnach ?
@ickc I've reviewed other PyPI modules and there's no standard for renaming things to be py-something so I'm going to roll back that specific commit. I'm going to be working with the library again since we're all stuck at home... I'll try not to break any interfaces if I add features ;)
@smarnach Any news on this? Be nice to have the forked version in PyPI. Thanks for all the effort so far.
@smarnach please
I see that there are multiple repos being forked with some of them more updated than others in terms of pull requests. So let's maybe form a plan or otherwise we can discuss for another year before moving anywhere forward with this issue. my proposal: let's first agree on what repo should the code continue forward and would be the authority to publish the package on pypi. Is it this one or some of the forks mentioned in the issue? Maybe the forks are also very different and we should create a new repo where we rebase and merge all the changes from those forks + pending pull requests etc; basically, prepare the code for release. I can then very easily add a CI pipeline that would auto-publish the package on pypi based on whatever is in master branch on that repo that we would agree on. At that point, we can formulate some contribution guidelines and maintenance of the code (incoming pull requests) so we can get regular updates which would be automatically released via that CI pipeline.
That's of course just my opinion so if you guys have better plan, objections or suggestions please share 😄
regarding the documentation, to me it looks like normal github-pages with static HTML. You can see it in https://github.com/smarnach/pyexiftool/tree/gh-pages so if you just generate sphinx docs into gh-pages branch it would publish that on github.io as static page.
When I evaluated it 10 months ago, the sylikc repo is most mature. He basically merged all the PR in this repo into his, and reflected in his CHANGELOG.md. There was a questionable renaming in his 0.4 but after communicating with him he rolled that back in 0.4.2.
I think his fork is pretty solid, unless if you have something better and can point us to look at it.
I think doing the ownership transfer and set up the necessary CI and PyPI is not the problem—they are very easy to do.
I think @smarnach already agreed to this. The hard work is how and when it happens.
Frankly I don't quite care about (2). Multiple forks of a package on PyPI is not new (even pyyaml has this.) (1) is much more important to inform people which repo is now the "authoritative" one to use. (1) can be easily done. Regarding the PyPI version, to me it suffices to say "package A is deprecated and please upgrade yours by installing its drop-in replacement by pip uninstall ... && pip install ...
."
I think @sylikc's intention is to have a drop-in replacement of this as can be shown by his effort to rolled the back change such that no changes on the user-side has to happen.
I'm happy to continue to improve PyExifTool . @RootLUG what other forks have features that I could/should pull into my fork?
With @ickc 's direction, I certainly want to maintain compatibility as much as possible and keep it a drop-in replacement for the library. As I edit/add features/calls, I am certainly mindful of not changing the existing behavior.
So, I can change the description on my project to say "up to date" or something. I guess I could set up another PyPI to have it installable through pip? Is that the preferred direction?
Just to clarify, I think unnecessary breaking change should be avoided, but in the (unlikely) event that a breaking change is needed, a clear communication with a major version increment would suffices.
My suggestion given the amount of time has passed already, would be to start a new PyPI repo maintained by @sylikc (with whatever different name deemed appropriate.) When @smarnach has the time then the only thing he need to do is to change the ownership of this repo to @sylikc. In the meanwhile, I hope this PR has given that fork a visibility enough for people to migrate smoothly.
Got it. Yeah, I'll keep that in mind.
Anyways, a new PyPI repo, any suggestions on names? Or I'll go with the super imaginative PyExifTool2 :D
@sylikc hey, thanks for taking a lead on that. Maybe for the name you could just use exiftool
?
Ah ha! I JUST noticed that I and @RootLUG have are assigned to be Maintainers of the PyExifTool project on PyPI! Thanks very much @smarnach . Let me see if I can get a release out soon
Actually, it looks like I was added awhile back lol. and the project is owned by @RootLUG . Oh well, same difference.
Still waiting for a ownership transfer of the repo though: https://docs.github.com/en/github/administering-a-repository/transferring-a-repository
Alright, I look forward to an ownership transfer of repository... one day
but in the meantime, I think I've figured out how to release the package. 0.4.5 is now the PyPI release... I fixed the exclusion of tests ... please test and make sure this package is in order.
I made a bunch of changes (my first published project) to the setup.py and such so it would dump out a description. I tested briefly in my environment, and it seems ok, but please do test.
starting discussions for direction of PyExifTool
Python 3.x in https://github.com/sylikc/pyexiftool/discussions/9 Planned re-design: https://github.com/sylikc/pyexiftool/discussions/10
Please discuss future topics there, and ideas. I'm also looking at other projects which may have wrapped exiftool as well and see what common functionality people usually use. I personally do a lot of metadata manipulation that I wish were a bit easier...
Alright, doesn't appear that any activity is happening over here. I'm going to tag all the people who've replied here to ask if you could review some of the code in my Python 3.x branch.
Since you're all users of PyExifTool, I presume, and to the very least, all changes I make, I want your valuable community input.
Please review the v0.5.x-py3-refactor
branch, and welcome to discuss it on https://github.com/sylikc/pyexiftool/discussions/10
@RootLUG @JSpenced @melyux @AutomationD @asielen
Thanks!
While this is unlikely to be merged, this PR provides some visibility to an active fork that has merged many other PR from here.