pyexiftool icon indicating copy to clipboard operation
pyexiftool copied to clipboard

Provide visibility for an active fork

Open ickc opened this issue 5 years ago • 25 comments

While this is unlikely to be merged, this PR provides some visibility to an active fork that has merged many other PR from here.

ickc avatar Dec 24 '19 23:12 ickc

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:

  • Add a link to the maintained fork in the README of this repo.
  • Try to get ownership of the PyPI packages someone created for this.
  • Get external links updated, e.g. the one from my StackOverflow answer.
  • Update the documentation link in the README to no longer point to the documentation hosted here.

smarnach avatar Dec 27 '19 10:12 smarnach

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.

ickc avatar Dec 27 '19 21:12 ickc

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.

ickc avatar Jan 05 '20 06:01 ickc

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.

sylikc avatar Feb 02 '20 01:02 sylikc

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.

sylikc avatar Feb 02 '20 01:02 sylikc

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.)

ickc avatar Feb 06 '20 11:02 ickc

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.

RootLUG avatar Feb 06 '20 11:02 RootLUG

I created an account on PyPI to prepare for a transfer. same username.

sylikc avatar Feb 06 '20 18:02 sylikc

@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.

smarnach avatar Feb 06 '20 21:02 smarnach

cool @smarnach how do I set up the githubio page for the documentation? is there an automated process to generate the docs?

sylikc avatar Feb 07 '20 04:02 sylikc

Sorry about the delay! This is still on my list, but I'm really busy at the moment. :-/

smarnach avatar Feb 16 '20 20:02 smarnach

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 ;)

sylikc avatar Apr 09 '20 11:04 sylikc

@smarnach Any news on this? Be nice to have the forked version in PyPI. Thanks for all the effort so far.

JSpenced avatar Jul 18 '20 16:07 JSpenced

@smarnach please

melyux avatar Oct 11 '20 03:10 melyux

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 😄

RootLUG avatar Oct 16 '20 13:10 RootLUG

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.

RootLUG avatar Oct 16 '20 13:10 RootLUG

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.

  1. transfer GitHub ownership of the repo
  2. PyPI ownership transfer

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.

ickc avatar Oct 16 '20 22:10 ickc

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?

sylikc avatar Oct 20 '20 00:10 sylikc

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.

ickc avatar Oct 20 '20 02:10 ickc

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 avatar Oct 21 '20 20:10 sylikc

@sylikc hey, thanks for taking a lead on that. Maybe for the name you could just use exiftool ?

DimmKirr avatar Dec 26 '20 19:12 DimmKirr

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

sylikc avatar Mar 12 '21 19:03 sylikc

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.

sylikc avatar Mar 13 '21 01:03 sylikc

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...

sylikc avatar Mar 13 '21 01:03 sylikc

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!

sylikc avatar Apr 18 '21 19:04 sylikc