ChiantiPy version confusion

[wtbarnes]

This isn't so much an issue with the codebase, but rather with how ChiantiPy is distributed.

In addition to this main repository on GitHub, ChiantiPy is still available via SourceForge as well as through a seemingly "stale" GitHub repo (doesn't seem to have been updated in the past year or so). It is also available via pip install ChiantiPy.

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

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

@Cadair Any thoughts on setting up a pipeline from GitHub to PyPI? How does SunPy do this?

The CHIANTI database webpage also still links to the SourceForge page 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. 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.

@kdere @ehsteve @Cadair Thoughts on this?

[Cadair]

So with SunPy I sign and upload sdist tarballs to pypi, which is reasonably straight forward. The full process for my SunPy release is here: https://gist.github.com/Cadair/9004780

@kdere Would you be interested in me building conda packages for ChiantiPy and the database for you? For SunPy we are now using the conda-forge machinery to make this easier. If we are going to have ChiantiPy as a dependancy of SunPy we will need the conda packages. It would be good to work with you on them.

[kdere]

yes there is version confusion with ChiantiPy.

First, I am very new to git/github. I have a fork that is a certain amount of commits ahead of the master and a certain number of commits behind the master. My local files seem to be at the same version as my fork.

I can do a pull request on github and add my commits to the master but I am a bit confused as to how to get my fork to the same level as the master. I think I did this once which involved reversing 'something'.

As for doing a release, I have usually done the

python setup.py sdist
and upload the tarball to sourceforge and PyPI.
I realize there is a mechanism on Github to create a release but have no idea what this does.

My current source of git/github info is 'Version Control with Git' by Loeliger and McCullough (O'Reilly). Can anyone suggest something better?

[wtbarnes]

I don't think separate forks on GitHub are the source of version confusion as these inherently refer back to the repo from which they were forked. However, the other "non-forked" versions of ChiantiPy on GitHub as well as the SourceForge page (which is still referenced by the CHIANTI webpage) create confusion about which is the "right" version of ChiantiPy.

That being said, the best way to get your fork even with the main chianti-atomic/ChiantiPy repository is to add an upstream to your local repository,

git remote add upstream https://github.com/chianti-atomic/ChiantiPy.git

This makes your local git repo aware of the repo that it was forked from. To check that it worked, use git remote -v and you should get something like,

origin  git@github.com:kdere/ChiantiPy.git (fetch)
origin  git@github.com:kdere/ChiantiPy.git (push)
upstream    https://github.com/chianti-atomic/ChiantiPy.git (fetch)
upstream    https://github.com/chianti-atomic/ChiantiPy.git (push)

Then to pull in changes from the master branch of the upstream we just added,

git pull upstream master

This should bring your local copy even with chianti-atomic/ChiantiPy, provided there are no conflicts to resolve (i.e. you haven't edited the same line of code as someone else). Just git push origin master to push those same changes up to your fork on GitHub. At this point, your fork should be 0 commits behind chianti-atomic/ChiantiPy and N commits ahead (depending on how much work you've done on your fork).

There's a lot of good git tips and info in the SunPy developer's guide as well. I'm not sure about a better reference text for git/GitHub.

[kdere]

I tried doing a pull request to send my edits to the upstream copy. It came back that my edits were incompatible with the upstream copy. Probably because I had edited files that had already been edited.

github suggested that I checkout a new branch and make changes and then push it back but the branch looked just like what I had. I think what I need to compare with is the upstream.

[wtbarnes]

I assume you are referencing PR #17. I suspect the conflicts are with some of the docstring fixes that I made.

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

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

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

[kdere]

I think what I will first do is cancel my pull request, then do your last pull you request. Then download a zip file of the upstream version and fix the local copy and my fork bit by bit. As you say, it should be clear what files have been modified.

[dpshelio]

@kdere - from the original issue mentioned by @wtbarnes I think the best is for me to delete the chiantidatabase organisation and the chiantipy repository within there:

https://github.com/chiantidatabase/

Let me know if you don't want me to do so before the end of the week.

[kdere]

At this time, I don't think we should be dealing with the chianti database itself, so it is fine to delete it.

[dpshelio]

Done - organisation and repository removed

[wtbarnes]

At the suggestion of @dpshelio here's a semi-exhaustive list of the other ChiantiPy repositories (not including forks) or ways to get ChiantiPy (not including this repository of course):

• GitHub: wkerzendorf/chiantipy
• GitHub: dpshelio/chiantipy-svn
• GitHub: dpshelio/chiantipy-only
• GitHub: aur-archive/python-chiantipy--from ArchLinux package archive, repo mostly empty
• GitHub: aur-archive/python2-chiantipy--from ArchLinux package archive, repo mostly empty
• Sourceforge
• PyPI package (aka pip)--even with Sourceforge?

[Cadair]

The aur-archive repos are the code for making arch Linux packages for chianti py, not copies of the source code. FYI.

[wtbarnes]

That's what I figured. Just including them for completeness.

[Cadair]

Interestingly the packages are not in the AUR any longer. I will rebuild them.

On 10 July 2016 15:31:35 BST, Will Barnes notifications@github.com wrote:

That's what I figured. Just including them for completeness.

---

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#16 (comment)

Sent from my Android device with K-9 Mail.

[dpshelio]

Thanks @wtbarnes - I had forgotten about these two repositories I created as intermediate steps. They are gone now.
@wkerzendorf's chiantipy seems to be a fork from the sourceforge repository from version 0.4.1 - I don't think that's a problem. I think pip and sourceforge should be updated and deprecated respectively.

[wtbarnes]

The ASCL entry for ChiantiPy also needs updating. It currently only links to the old Sourceforge version.

[kdere]

thanks for checking.
I have been running in circles trying to figure out how to include mathjax (or imgmath) for my local doc builds. I think I have some good leads to follow but if anyone has some good ideas I would appreciate them.

[wtbarnes]

I think this issue has been a bit forgotten, but it seems this problem of multiple versions still exists:

• SourceForge repo still exists with some active discussion as late as June of this year
• CHIANTI website still lists the SourceForge site
• ASCL lists SourceForge as the only source for ChiantiPy

EDIT:
The user guide page on the CHIANTI site also links to the old Sphinx docs hosted on SourceForge. Ideally this should link to the more up to date build on Read the Docs.

I would argue for removing the SourceForge page because it is likely to confuse users. It doesn't look like the SVN history was migrated over to the GitHub repo, but it looks like this could be done fairly easily so that ChiantiPy's long pre-git history is preserved!

[kdere]

OK, I will go in and edit these.
There is still an old version 0.6.x on PyPI that should be updated but at present we have some well known bugs in ChiantiPy. Of course, these are in the 0.6.x files as well.

[wtbarnes]

We should tag a release on GitHub consistent with the latest release (v0.6.5?) on PyPI as recently announced on the mailing list. See tagging releases on GitHub.

[kdere]

First, I need to see that the same errors are not in the github version. That was next on my list.

[wtbarnes]

So the code that is in PyPI/SourceForge is completely different from that in the GitHub repo?

[kdere]

The code PyPI/SourceForge is not completely different but it has been a long time since I have I have worked on it and it has not kept up with github. I do not want to maintain the old SF code any longer than I have to but yesterday, it was the fastest way to fix someone's problems.

I have happy to make a new release on Github soon. The same errors in the SF spectrum code was in the github and I have just fixed them.

[ehsteve]

@kdere I just did a google search for chiantipy and the first link was the sourceforge version. I can see that this would create user confusion if that version is no longer being developed. I would highly suggest that the main page for chiantipy sourceforge state in big red letters that it should not be used and provide a link to this version.

[wtbarnes]

My suggestion would be to migrate the old SourceForge repo to a new, separate GitHub repo (call it chianti-atomic/ChiantiPy-archive) and then delete the SourceForge repo altogether. With this archived repo, we can then go about solving #113

I think the most pressing problem is that the CHIANTI webpage, which is most peoples first (and last) stop for information about CHIANTI, still lists the SourceForge repo and docs in multiple places.

[kdere]

I did not notice that particular page. I will fix it.

The only reason I still have a Sourceforge account is for the svn for the old stuff. If we can just load it directly onto github that would be fine

[kdere]

Fixed that

[Cadair]

It is also possible to graft the history of the svn repo into here. It would mean a bit of git faffery for everyone but it's very doable. The other option is that we can have a branch in this repo which is the old history.

[Cadair]

I have a branch here: https://github.com/Cadair/ChiantiPy/tree/archive you could pull into this repo, which is the snv history. (I just used https://import.github.com). I could also rebase master onto that repo if @kdere could tell me at what revision this repo started.

[wtbarnes]

@kdere there are still two spots on the CHIANTI webpage where the SourceForge docs are linked to:

• User Guide page
• Chianti Family page

[kdere]

OK, those bugs were squashed

[wtbarnes]

@Cadair The initial commit to the new ChiantiPy GitHub repo is here on 17 February of last year.

Looking at the archive you ported over, only the last commit (on 18 March 2016) in the SVN repo is newer than the first GitHub commit. So I think you should be able to rebase your archive branch onto master starting at 76d4e1ea6d9bbae6024f3a9593cb2d9653ca2ef1.

[wtbarnes]

@kdere Out of curiosity, how is the CHIANTI webpage managed? Is it just a collection of HTML on an FTP server? It might be convenient to move the webpage code over to GitHub and it could live under the chianti-atomic org. That way, bugs/typos with the webpage could be reported in a specific place. You could also use Travis CI to automatically redeploy the site at every new commit.

[kdere]

Yes, the CHIANTI web pages are just html files on a web server and I maintain the site. The files are under svn. However, the CHIANTI team, aside from myself, is quite separate from the ChiantiPy team. However, it would also allow everyone on the team. So, I will think about that.

[ebuchlin]

Hello,
I'm coming back to this old issue as I see that installing CHIANTI with pip still gives v0.6.5, while v0.7.0 has been released a while ago. This must be because PyPI still lists v0.6.5 as latest version. Would some action from the ChiantiPy project be needed for this?

[kdere]

perhaps the thing to do would be to delete the old versions. I will look into this

[kdere]

When I looked at PyPI, the latest was given as 0.7.1a0. However, I just deleted the older versions. The only version that is now available is 0.7.1a0.

[ebuchlin]

Thanks!

[adamrkob]

Can you clarify which version a new user should be using? I just installed it/cloned it from GitHub on a new machine today and it looks to be version 0.8 . Looking through the documentation and this thread, I can't determine whether I should be tracking down a version 0.71 instead.
Unfortunately, I haven't been able to run the tests with the version I just installed, I get an error in ChiantiPy/init.py when importing ChiantiPy.core:

In [1]: import ChiantiPy.core as ch

ImportError Traceback (most recent call last)
~/ChiantiPy/ChiantiPy/init.py in
41 try:
---> 42 from . import version
43 Version = version._last_generated_version

ImportError: cannot import name 'version'

During handling of the above exception, another exception occurred:

ImportError Traceback (most recent call last)
in
----> 1 import ChiantiPy.core as ch

~/ChiantiPy/ChiantiPy/init.py in
43 Version = version._last_generated_version
44 except:
---> 45 from . import static_version
46 Version = static_version.version
47 Version_info = static_version.version_info

ImportError: cannot import name 'static_version'

In [2]: ChiantiPy.version

NameError Traceback (most recent call last)
in
----> 1 ChiantiPy.version

NameError: name 'ChiantiPy' is not defined

I can't tell if this is an error in my setup (not uncommon for me). It is a new macOS setup in Mojave using python 3.6.6 from Conda, or if it is a potential issue with the actual ChiantiPy. Can you clarify if I should track down 0.71 so I can trouble shoot? Thanks and sorry if this is purely on my end.

[kdere]

The version in the repository is for 0.8.0 and I do need to release it as soon as possible. I will work on it today.
The version now requires Python 3 (it is being developed under Python 3.6) It also requires PyQt5
the Documentation has moved to github.io http://chianti-atomic.github.io/

[kdere]

I think it is OK now and should be ready for a 0.8.0 release. The 2 doc sites list it as version 0.8.0
If you would like to try it again, I would like to hear how it goes.
thanks for giving it a try.

[adamrkob]

Thank you! That fixed it all right up. I can now use the basic tools and have verified I am running version 0.8.0. Adam

…

On Oct 21, 2018, at 16:05, Ken Dere ***@***.***> wrote: I think it is OK now and should be ready for a 0.8.0 release. The 2 doc sites list it as version 0.8.0 If you would like to try it again, I would like to hear how it goes. thanks for giving it a try. — You are receiving this because you commente Reply to this email directly, view it on GitHub, or mute the thread.

[kdere]

glad to hear that. I will be making a version 0.8.0 soon.