{"action":"created","issue":{"url":"https://api.github.com/repos/chianti-atomic/ChiantiPy/issues/16","repository_url":"https://api.github.com/repos/chianti-atomic/ChiantiPy","labels_url":"https://api.github.com/repos/chianti-atomic/ChiantiPy/issues/16/labels{/name}","comments_url":"https://api.github.com/repos/chianti-atomic/ChiantiPy/issues/16/comments","events_url":"https://api.github.com/repos/chianti-atomic/ChiantiPy/issues/16/events","html_url":"https://github.com/chianti-atomic/ChiantiPy/issues/16","id":162526920,"number":16,"title":"ChiantiPy version confusion","user":{"login":"wtbarnes","id":8676141,"avatar_url":"https://avatars.githubusercontent.com/u/8676141?v=3","gravatar_id":"","url":"https://api.github.com/users/wtbarnes","html_url":"https://github.com/wtbarnes","followers_url":"https://api.github.com/users/wtbarnes/followers","following_url":"https://api.github.com/users/wtbarnes/following{/other_user}","gists_url":"https://api.github.com/users/wtbarnes/gists{/gist_id}","starred_url":"https://api.github.com/users/wtbarnes/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/wtbarnes/subscriptions","organizations_url":"https://api.github.com/users/wtbarnes/orgs","repos_url":"https://api.github.com/users/wtbarnes/repos","events_url":"https://api.github.com/users/wtbarnes/events{/privacy}","received_events_url":"https://api.github.com/users/wtbarnes/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":5,"created_at":"2016-06-27T19:17:24Z","updated_at":"2016-07-05T04:22:24Z","closed_at":null,"body":"This isn't so much an issue with the codebase, but rather with how ChiantiPy is distributed.\r\n\r\nIn addition to this main repository on GitHub, ChiantiPy is still available via [SourceForge](http://chiantipy.sourceforge.net//index.html) as well as through a seemingly [\"stale\" GitHub repo](https://github.com/chiantidatabase/chiantipy) (doesn't seem to have been updated in the past year or so). It is also available via `pip install ChiantiPy`.\r\n\r\nThe problem here is that, as far as I can tell, each of these sources holds a different version of ChiantiPy. I think this has the potential to really confuse users, especially those that may be hesitant to move to Python (from IDL) in the first place.\r\n\r\nIt seems that most development of ChiantiPy has now moved to this GitHub repo. I would propose removing the version on SourceForge (or at least stop linking to it) as well as the stale version that is on GitHub. Then the most current and stable version of this repo can be pushed to PyPI so that users can obtain it via `pip install` as well. In this way, the code is being distributed from a single source and there is less of a risk of a user accidentally downloading it from the \"wrong\" place. \r\n\r\n@cadair Any thoughts on setting up a pipeline from GitHub to PyPI? How does SunPy do this?\r\n\r\nThe [CHIANTI database webpage](http://www.chiantidatabase.org/) also still links to the [SourceForge page](http://chiantipy.sourceforge.net//) though it looks like there is a link to the GitHub page as well. I would propose linking only to this GitHub repo and the [Read the Docs page](http://chiantipy.readthedocs.io/en/latest/). It might also be helpful to current and future users to make an announcement about the Read the Docs page and encourage them to report issues/request features via GitHub. \r\n\r\n@kdere @ehsteve @cadair Thoughts on this? "},"comment":{"url":"https://api.github.com/repos/chianti-atomic/ChiantiPy/issues/comments/230384860","html_url":"https://github.com/chianti-atomic/ChiantiPy/issues/16#issuecomment-230384860","issue_url":"https://api.github.com/repos/chianti-atomic/ChiantiPy/issues/16","id":230384860,"user":{"login":"wtbarnes","id":8676141,"avatar_url":"https://avatars.githubusercontent.com/u/8676141?v=3","gravatar_id":"","url":"https://api.github.com/users/wtbarnes","html_url":"https://github.com/wtbarnes","followers_url":"https://api.github.com/users/wtbarnes/followers","following_url":"https://api.github.com/users/wtbarnes/following{/other_user}","gists_url":"https://api.github.com/users/wtbarnes/gists{/gist_id}","starred_url":"https://api.github.com/users/wtbarnes/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/wtbarnes/subscriptions","organizations_url":"https://api.github.com/users/wtbarnes/orgs","repos_url":"https://api.github.com/users/wtbarnes/repos","events_url":"https://api.github.com/users/wtbarnes/events{/privacy}","received_events_url":"https://api.github.com/users/wtbarnes/received_events","type":"User","site_admin":false},"created_at":"2016-07-05T04:22:24Z","updated_at":"2016-07-05T04:22:24Z","body":"I assume you are referencing PR #17. I suspect the conflicts are with some of the docstring fixes that I made. \r\n\r\nAssuming you've made all of these changes on `master` locally, I would try first adding the upstream to your local repo and then do a `git pull upstream master`. This will attempt to merge in all the changes from the upstream `master` branch into your local `master` branch.\r\n\r\nThe merge will not be successful because of the existing conflicts. However, git should give you a list of the files where these conflicts occur and mark them appropriately. [Here's a really brief description of how git handles conflicts](https://help.github.com/articles/resolving-a-merge-conflict-from-the-command-line/). Once you are successfully able to merge in the upstream `master` branch, do a `git push origin master` to update PR #17. It should then show no conflicts. \r\n\r\nI think resolving these conflicts shouldn't be too messy. Looking at the commits on your fork of ChiantiPy since the last merge with upstream, I see very few conflicts with changes I made. Most (if not all) are  in `util.py` and `io.py`. \r\n\r\n "}}
{"actor":{"display_login":"wtbarnes"}}