These are chat archives for SHTOOLS/SHTOOLS

8th
Dec 2016
Ilya Oshchepkov
@ioshchepkov
Dec 08 2016 07:45
How about to move spectralanalysis and localizedspectralanalysis into one subpackage spectral to avoid long names?
Also, to avoid naming classes, maybe it is good to move all shgrid.py, shcoeffs.py and shwindow.py into something like core subpackage? I mean, there will be another classes...
Mark Wieczorek
@MarkWieczorek
Dec 08 2016 09:49
I already moved localizedspectralanalysis into spectralanalysis. Let me think about shortening it even more....
I've given up on the cyclic imports. As far as I can tell, this can not be done in both python 2 and 3 with relative imports. I'll just break the one file into shwindow.py and shcoeffsgrid. I don't really care what the subpackage name is that hold the classes. Are there any other ideas?
Mark Wieczorek
@MarkWieczorek
Dec 08 2016 12:05
I just tagged v4.0-rc1. If we don't run into any problem, I was thinking of a release in one week (dec 16). We can still make changes, but the only things I see are potential renaming that module that contains all the pyshtools classes, and perhaps adding projections to the plotting routines.
Mark Wieczorek
@MarkWieczorek
Dec 08 2016 12:23

concerning the release procedure, I just noted this in the setup.py file

# This flag has to be True if the version number indicated in the file
# VERSION has already been released and to False if this is a development
# version of a future release.
ISRELEASED = True

Should we set this to false on the develop branch? And if not, perhaps we should clarify what this means. It is not really clear to me...

and @MMesch should we try uploading this to pypitest? I think that it is you with the account info, and I've never done this before.
Ilya Oshchepkov
@ioshchepkov
Dec 08 2016 12:40
get_version function from setup.py will try to get version from tag first, next it will try to check if there any changes were made from tag's commit. If not, then version is equal to the tag, if yes, then it'll add .post to version if isreleased is True and .dev if it is not True. .post is supposed to be used for small changes after major release and .dev is for development stage in which we are now. So, now, nearly before release, we should change it to False and change version in VERSION file to 4.0. This versioning system actually does not welcome any -rc1 tags...
Ilya Oshchepkov
@ioshchepkov
Dec 08 2016 12:53
This can be more plain if right after release we'll decide next version number (4.1) and in develop branch change version number to it and ISRELEASED=False. If something will needed to be changed in master, then a new branch can be created for this purpose. In other words, develop is always for the next release
Ilya Oshchepkov
@ioshchepkov
Dec 08 2016 13:07
My suggestion is to drop Python 2 support completely in the next versions, say 5.0 or maybe earlier. Many core libraries are planning to do so until 2020, when Python 2.7 support ends. I don't know how many people are using SHTOOLS with version 2, but it is a good time to move on while we are doing so many changes in all parts of the library code