ChiantiPy version confusion about chiantipy HOT 42 CLOSED

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

from chiantipy.

Done - organisation and repository removed

from chiantipy.

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

from chiantipy.

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.

from chiantipy.

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?

from chiantipy.

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  [email protected]:kdere/ChiantiPy.git (fetch)
origin  [email protected]: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.

from chiantipy.

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.

from chiantipy.

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.

from chiantipy.

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.

from chiantipy.

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

from chiantipy.

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?

from chiantipy.

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

from chiantipy.

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

from chiantipy.

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

On 10 July 2016 15:31:35 BST, Will Barnes [email protected] 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.

from chiantipy.

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.

from chiantipy.

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

from chiantipy.

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.

from chiantipy.

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!

from chiantipy.

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.

from chiantipy.

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.

from chiantipy.

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

from chiantipy.

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

from chiantipy.

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.

from chiantipy.

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.

from chiantipy.

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

from chiantipy.

Fixed that

from chiantipy.

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.

from chiantipy.

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.

from chiantipy.

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

• User Guide page
• Chianti Family page

from chiantipy.

OK, those bugs were squashed

from chiantipy.

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

from chiantipy.

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

from chiantipy.

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.

from chiantipy.

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?

from chiantipy.

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

from chiantipy.

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.

from chiantipy.

Thanks!

from chiantipy.

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.

from chiantipy.

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/

from chiantipy.

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.

from chiantipy.

from chiantipy.

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

from chiantipy.