New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrating repo to the manubot organization #94

Closed
dhimmel opened this Issue Jan 31, 2019 · 8 comments

Comments

Projects
None yet
3 participants
@dhimmel
Copy link
Member

dhimmel commented Jan 31, 2019

We are now in possession of the @manubot account, which will be the organization where we want to move all Manubot related repositories.

However, we have to be careful that we migrate repos from the @greenelab to @manubot organization in such a way that is not disruptive.

See the GitHub docs on Transferring a repository:

If the transferred repository contains a GitHub Pages site, then links to the Git repository on the Web and through Git activity are redirected. However, we don't redirect GitHub Pages associated with the repository.

All links to the previous repository location are automatically redirected to the new location. When you use git clone, git fetch, or git push on a transferred repository, these commands will redirect to the new repository location or URL. However, to avoid confusion, we strongly recommend updating any existing local clones to point to the new repository URL. You can do this by using git remote on the command line:

@dhimmel

This comment has been minimized.

Copy link
Member Author

dhimmel commented Jan 31, 2019

Currently, manubot-rootstock pip installs manubot using:

    - git+https://github.com/greenelab/manubot@552dd99aaa148365a29a87176fedd626d4642d3c

We have already moved one repository. First, we transferred https://github.com/greenelab/manubot-resources to https://github.com/manubot/manubot-resources and then renamed the repository to https://github.com/manubot/resources.

Therefore I tested the following command:

pip install git+https://github.com/greenelab/manubot-resources@a2ba7bf542ef47f81c93bb512df3e10dc7741344

Which returned

Collecting git+https://github.com/greenelab/manubot-resources@a2ba7bf542ef47f81c93bb512df3e10dc7741344
  Cloning https://github.com/greenelab/manubot-resources (to revision a2ba7bf542ef47f81c93bb512df3e10dc7741344) to /tmp/pip-req-build-m31jjnxf
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/home/dhimmel/anaconda3/lib/python3.6/tokenize.py", line 452, in open
        buffer = _builtin_open(filename, 'rb')
    FileNotFoundError: [Errno 2] No such file or directory: '/tmp/pip-req-build-m31jjnxf/setup.py'

Therefore, it looks like the redirect succeeded. pip install was able to clone greenelab/manubot-resources. Eventually the install fails because the repo lacks a setup.py file. Therefore, existing rootstock environments should continue to install, so I can't think of any blockers preventing us from migrating this repo.

@dhimmel

This comment has been minimized.

Copy link
Member Author

dhimmel commented Jan 31, 2019

Rename to indicate python package?

Another question is whether we want to rename this repo to something like manubotpy or pymanubot, to indicate that it is the python package and not necessarily the entire manubot? We would still keep the name on PyPI as manubot and the CLI command as manubot.

I don't necessarily have another repo that I'd like to call manubot so maybe this is premature. @agitter what do you think?

@agitter

This comment has been minimized.

Copy link
Member

agitter commented Jan 31, 2019

I have come to think of the functions implemented in this repository as "Manubot" so I would be happy to continue using the repository name manubot instead of adding a py prefix or suffix. Renaming and transferring repositories in GitHub has worked well for me in general. However, if we were to later rename this to manubot/manubot-py and then create a different manubot/manubot, that might cause problems.

@agitter

This comment has been minimized.

Copy link
Member

agitter commented Jan 31, 2019

What will happen with the manubot-rootstock repository? That could be trickier to migrate than manubot. If we transfer it, the old upstream remotes should still work. However, if I understand the quoted text above, the GitHub Pages for the past example manuscripts will be broken. Is that correct?

@dhimmel

This comment has been minimized.

Copy link
Member Author

dhimmel commented Jan 31, 2019

However, if we were to later rename this to manubot/manubot-py and then create a different manubot/manubot, that might cause problems.

Yes it would. We would have to rename it to greenelab/manubot-py and then transfer the repository to manubot/manubot-py. However, sounds like we are okay keeping the name as manubot.

@agitter if you are okay with manubot/manubot, I'll do that migration. I may have to reconfigure some aspects of the CI (not sure yet).

What will happen with the manubot-rootstock repository?

I was thinking we'd move it to manubot/rootstock and that we'd do this last because it's the most complicated.

However, if I understand the quoted text above, the GitHub Pages for the past example manuscripts will be broken. Is that correct?

Yes. This URL will not be redirected https://greenelab.github.io/manubot-rootstock/. We'd likely just have to live with that: all the workarounds I can think of have negative side effects. For example, if we migrate rootstock but then create a manubot-rootstock repository at greenelab for redirects, then issue and PR links will break.

@cgreene

This comment has been minimized.

Copy link

cgreene commented Jan 31, 2019

@dhimmel

This comment has been minimized.

Copy link
Member Author

dhimmel commented Jan 31, 2019

What if you put up an html page there that just does a javascript redirect?

Then we have to have a repository located at greenelab/manubot-rootstock. Having this repository prevents URLs like manubot/rootstock@ec359f6 from redirecting. This would therefore break all existing commit / PR / issue links, which are probably more important. Now we could keep the existing manubot-rootstock repo so commit links would still work. However, PR and issues with still break, unless we duplicate them which is undesirable for its own reasons. We could duplicate and lock them with a final comment noting the new location.

@agitter

This comment has been minimized.

Copy link
Member

agitter commented Jan 31, 2019

@agitter if you are okay with manubot/manubot, I'll do that migration.

Yes, this migration is more straightforward, and I agree you can proceed.

We should wait to do the manubot/rootstock migration and possibly let more of the @manubot organization members weigh in. I currently think that it is most important to maintain the automatic redirects for the remote repository links that are used for syncing and then the commit / PR / issue links. Keeping the versioned example manuscripts would be nice, but is not as critical.

Is this a more general problem that we need to discuss in a separate manubot rootstock issue? It looks like anyone who renames a repository would also lose their permalinked manuscripts per https://help.github.com/articles/renaming-a-repository/

@dhimmel dhimmel closed this in #96 Feb 2, 2019

dhimmel added a commit to dhimmel/manubot-rootstock that referenced this issue Feb 6, 2019

Update repo to https://github.com/manubot/manubot
greenelab/manubot relocated to manubot/manubot as per
manubot/manubot#94.

02.delete-me.md still references greenelab/manubot,
however it is not worth creating merge conflicts to
update just this.

dhimmel added a commit to manubot/rootstock that referenced this issue Feb 6, 2019

shortDOI support & update environment on 2019-02-06
Merges #174

* Environment update on 2019-02-06

Does not upgrade weasyprint or cairo, due to the following error during
WeasyPrint execution:
OSError: dlopen() failed to load a library: cairo / cairo-2 / cairo-gobject-2

Specify cairocffi dependency in environment.yml, since v0.9 from PyPI
seemed to trigger the OSError.

* Add shortDOI support & usage

Update repo to https://github.com/manubot/manubot
greenelab/manubot relocated to manubot/manubot as per
manubot/manubot#94.

02.delete-me.md still references greenelab/manubot,
however it is not worth creating merge conflicts to
update just this.

dhimmel added a commit to manubot/rootstock that referenced this issue Feb 6, 2019

shortDOI support & update environment on 2019-02-06
This build is based on
f559600.

This commit was created by the following Travis CI build and job:
https://travis-ci.org/greenelab/manubot-rootstock/builds/489622322
https://travis-ci.org/greenelab/manubot-rootstock/jobs/489622323

[ci skip]

The full commit message that triggered this build is copied below:

shortDOI support & update environment on 2019-02-06

Merges #174

* Environment update on 2019-02-06

Does not upgrade weasyprint or cairo, due to the following error during
WeasyPrint execution:
OSError: dlopen() failed to load a library: cairo / cairo-2 / cairo-gobject-2

Specify cairocffi dependency in environment.yml, since v0.9 from PyPI
seemed to trigger the OSError.

* Add shortDOI support & usage

Update repo to https://github.com/manubot/manubot
greenelab/manubot relocated to manubot/manubot as per
manubot/manubot#94.

02.delete-me.md still references greenelab/manubot,
however it is not worth creating merge conflicts to
update just this.

dhimmel added a commit to manubot/rootstock that referenced this issue Feb 6, 2019

shortDOI support & update environment on 2019-02-06
This build is based on
f559600.

This commit was created by the following Travis CI build and job:
https://travis-ci.org/greenelab/manubot-rootstock/builds/489622322
https://travis-ci.org/greenelab/manubot-rootstock/jobs/489622323

[ci skip]

The full commit message that triggered this build is copied below:

shortDOI support & update environment on 2019-02-06

Merges #174

* Environment update on 2019-02-06

Does not upgrade weasyprint or cairo, due to the following error during
WeasyPrint execution:
OSError: dlopen() failed to load a library: cairo / cairo-2 / cairo-gobject-2

Specify cairocffi dependency in environment.yml, since v0.9 from PyPI
seemed to trigger the OSError.

* Add shortDOI support & usage

Update repo to https://github.com/manubot/manubot
greenelab/manubot relocated to manubot/manubot as per
manubot/manubot#94.

02.delete-me.md still references greenelab/manubot,
however it is not worth creating merge conflicts to
update just this.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment