Obspy: Release 1.2.0

[megies]

@obspy/developers @obspy/packagers @obspy/conda-forgers
@ThomasLecocq, @krischer and myself will meet for a few days mid February for a little ObsPy sprint. The agenda is kinda obvious, so I hope we'll manage to get at least 1.1.1 out and hopefully also 1.2.0. That means any PRs not in good shape or merging by then will definitely postponed.

[megies]

Python 2 goes EOL Jan 1st 2020, right? So, given our actual release cycle, I guess we might as well switch to Python 3 only right after 1.2.0?

[megies]

@obspy/developers @obspy/packagers @obspy/conda-forgers we're trying to finalize 1.2.0 on March 15th, i.e. next Friday

[ThomasLecocq]

@megies OK, taking the day off work then, so I can help more.

[megies]

@megies OK, taking the day off work then, so I can help more.

Cool!

[megies]

We (CC @krischer) were talking about the post-1.2.0 future and thought it might be a good idea to bump the minimum Python (and dependency) versions significantly by ignoring some of the older distributions out there. For Debian that would mean not shipping 2.0.x packages for Debian 9 "stretch" (the current stable) although it's LTS until 2022, but instead only targeting the next stable release "buster" which should be out in summer with Python 3.7 in it. This would mean when we make the big switch, we can also focus on making good use of new Python 3 functionality.

Any thoughts?

[d-chambers]

I guess we should decide on the lowest version of python obspy 2.0.x will support then use that to determine which distributions we can support?

For me python 3.6 feels modern enough, and python 3.5 will likely be EoL before we get 2.0 out.

Off topic here, but the major version bump also affords us the rare opportunity to make significant, potentially breaking, changes. It might be good to setup a place to discuss some of these as we won't get another chance for a long time.

[trichter]

We (CC @krischer) were talking about the post-1.2.0 future and thought it might be a good idea to bump the minimum Python (and dependency) versions significantly by ignoring some of the older distributions out there

I agree with this roadmap. Nowadays its also fast & easy to get everything setup with conda on unsupported systems.

[krischer]

I think we should definitely go at least to Python 3.6 for f-strings and type-annotations on variables. I'm also in favor of going directly to Python 3.7 and establish it as a new baseline for the next few releases. We'll do breaking changes in any case so I'd argue it's a "why not?" questions.

Things from 3.7 that might actually be useful:

• Module level __getattr__().
• https://docs.python.org/3/whatsnew/3.7.html#whatsnew37-pep563 - otherwise forward references quickly become annoying
• A dictionary is now always ordered according to the language spec (although this - in cpython - is also true in practice for Python 3.6)
• Actual nanosecond resolution times: https://www.python.org/dev/peps/pep-0564/
• Dataclasses: https://docs.python.org/3/library/dataclasses.html

Are there any good reasons to only go to 3.6 instead of 3.7?

Off topic here, but the major version bump also affords us the rare opportunity to make significant, potentially breaking, changes. It might be good to setup a place to discuss some of these as we won't get another chance for a long time.

Anything specific you have in mind? There are a few default kwargs I would set differently in retrospect but I feel like that is actually too dangerous even if we allow breaking changes because it would porting codes much harder. Otherwise I don't see a lot as we cleaned up the code base for 1.0 quite a bit. But maybe I am just so used to ObsPy that I don't see its idiosyncrasies anymore.

[d-chambers]

Are there any good reasons to only go to 3.6 instead of 3.7?

None related to the language, but if you recall the last time we made a graph of our pip downloads the majority were coming from 3.6, so perhaps it would make the upgrade path a little easier for some people if we only required 3.6.

However, it could be that many more have switched to 3.7 since I last generated that figure.

Anything specific you have in mind?

There are some things related to immutability of UTCDateTime (#2072) and ResourceIdentifier (#2303) but these have already been discussed. There are also other small inconsistencies that could be corrected, but I am not thinking of anything major here.

@krischer, you mentioned that some are of the opinion obspy has become too large and should be split up a bit, e.g. turning seishub into its own package, potentially splitting up the IO and processing layers, etc. There are a whole host of possible structural changes that perhaps we should discuss because we likely wont get another chance for 5 years or so to implement them.

I would like to see the test runner migrated to pytest (working on it in the pytestify branch) and this will probably cause some backwards incompatible changes to how tests are run, but hopefully these will be very minor.

We might consider switching to Numpy style docs for a more human-readable command-line experience, and because most other scientific packages use them (eg astropy, numpy, scipy, sklearn, ...).

One thing that has always bothered me is that any of the Trace/Stream operations occur in-place by default. Although the docs are very clear, it has still been a pain-point to lookup the docs for every operation to know if it is going to act in place or return a copy. It would, IMHO, be better/safer to always return a copy unless inplace=True is used, which is generally what pandas does. It could also reduce the API surface area a bit (eg only Stream.slice or Stream.trim would be needed). Admittedly, this would be a painful and radical change, but it might be possible with the right depreciation path.

Others may have additional ideas that are worth discussing.

[jkmacc-LANL]

FWIW, I like all the changes @d-chambers mentioned.

[lijunzh]

at least to Python 3.6 for f-strings and type-annotations on variables

These are the two features I'd love to have as well.

[heavelock]

I would vote for bumping the minimum version up to 3.7. Apart of mentioned dataclasses, nanosecond resolution that probably will be helpful for #2072 and postponed evaluation of annotations, 3.6 will be EoL in December 2021 which doesn't give too much time for releasing 2.0 before that.

I also feel totally moving to pandas-style return copy policy. After getting used to that it is actually very handy and safer in a lot of cases.

Did you think about using Black? (https://github.com/ambv/black)

[trichter]

In contrast, I find it more intuitive with the in-pace operations of stream. If you don't want that, you can always copy the stream before the operation, e.g. stream = stream.copy().filter(...).

[krischer]

There are some things related to immutability of UTCDateTime (#2072) and ResourceIdentifier (#2303) but these have already been discussed. There are also other small inconsistencies that could be corrected, but I am not thinking of anything major here.

:+1: For all of these!

@krischer, you mentioned that some are of the opinion obspy has become too large and should be split up a bit, e.g. turning seishub into its own package, potentially splitting up the IO and processing layers, etc. There are a whole host of possible structural changes that perhaps we should discuss because we likely wont get another chance for 5 years or so to implement them.

Some people have mentioned that they would like to have an "ObsPyLite". The rational was to make it easier to build and ship things using ObsPy. As far as I understood the problem it was never ObsPy that was the issue but more all the dependencies. Thus what I think we could do is make ObsPy usable without all dependencies available. Our current list of mandatory dependencies are:

• future - no longer needed after 1.2
• numpy - always needed
• scipy - needed for processing
• matplotlib - needed for plotting
• lxml - needed for the XML I/O formats
• setuptools - I'm not entirely sure if this still must be a runtime dependency
• sqlalchemy - Only needed for obspy.db thus could be optional
• decorator - very much needed. We could consider vendoring this.
• requests - Very useful but we actually don't use this a lot yet. If we move to Python 3 only we could (and maybe should) consider moving to urllib again as that is not much harder if we don't have to worry about python 2 support.

Thus we could actually have ObsPy working with only numpy installed. I don't want to build differrent packages but some things would just not work without the corresponding packages installed. We could enforce this in the CI.

• Python + NumPy: Only I/O is usable. Still useful for many file conversion tasks.
• Above + lxml: XML things can be read.
• Above + SciPy: Processing becomes available
• Above + Matplotlib: Plotting is there
• Above + sqlalchemy: Other things are there.

What do you guys think? This might actually not be that much work.

Also I think we should ship the pypi packages without all the test and test data - that would make them A LOT smaller. It is still possible to test these packages by just running the tests in another folder.

I would like to see the test runner migrated to pytest (working on it in the pytestify branch) and this will probably cause some backwards incompatible changes to how tests are run, but hopefully these will be very minor.

I'd argue we can do whatever we want with the tests as it is not part of the official API surface.

We might consider switching to Numpy style docs for a more human-readable command-line experience, and because most other scientific packages use them (eg astropy, numpy, scipy, sklearn, ...).

I would not mind at all! But that is going to be one hell of a grind! If we do it we should also get rid of all the :type: specifiers or however they look in the numpy doc style and just use type annotations.

One thing that has always bothered me is that any of the Trace/Stream operations occur in-place by default. Although the docs are very clear, it has still been a pain-point to lookup the docs for every operation to know if it is going to act in place or return a copy. It would, IMHO, be better/safer to always return a copy unless inplace=True is used, which is generally what pandas does. It could also reduce the API surface area a bit (eg only Stream.slice or Stream.trim would be needed). Admittedly, this would be a painful and radical change, but it might be possible with the right depreciation path.

I'm very strongly not in favor of this. I do see the beauty of the approach but this would IMHO be too big of a breaking change and essentially break every existing ObsPy script. I would not mind adding inplace kwargs to the methods (this could actually be handled by a simple decorator) but the default for most things should definitely be True! Everything except slice() is in-place right now. I think this is also the more natural working order for seismologists - one usually has a linear processing chain and rarely needs access to the intermediate results (and .copy() is still available in cases where one does as @trichter points out).

I do agree that we should consolidate .trim() and .slice() to use the same logic but that is possible in any case.

[barsch]

Any reason to keep obspy.db? I would just remove it as well as obspy.clients.seishub ...

concerning Python versions: everything above 3.5 is fine for me

[megies]

some are of the opinion obspy has become too large and should be split up a bit

Thus we could actually have ObsPy working with only numpy installed. I don't want to build differrent packages but some things would just not work without the corresponding packages installed. We could enforce this in the CI.

This is a trade-off between..

• a very small group of people that have very special needs using only parts of obspy (and those people are very likely able to simply work around e.g. by monkey-patching setup.py before installing from source etc. or tweakin the dependency infos in the conda packages)
• a large group of non-experienced users that might trip over missing dependencies and are confused that things are not working when they expect they should. you're lucky if you have no history of people asking you about how to fix an ImportError or what it even means, but I am sure that we will get questions from a lot of confused people

So I don't like the sounds of it, unless we are talking something simple, like repackaging with tweaked hard dependency info in the (conda) packages.

Actually.. thinking a bit more about this I guess we could..

• move everything besides numpy intro EXTRAS_REQUIRE in setup.py
• still use all the normal dependencies like it is now in the conda recipe (dunno about pypi built packages)

Then people could actually simply opt-out of installing dependencies with conda install --no-deps obspy and just install what they need in terms of dependencies (basically working with an environment that would seem broken to the conda package solver).

Still.. overall I don't really like all this..

(Debian packaging is very convenient in that regard. For deb packages you can specify hard dependencies and recommended dependencies that can be opted out during install with one CL option -- unfortunately conda doesn't have that fine-grained dependency categorization approach)

in favor of going directly to Python 3.7

Going to Python 3.7 would probably mean dropping most ongoing packaging efforts (in terms of nix-distributions). At least it would mean dropping Debian packaging (I'd drop Ubuntu then as well) and certainly all the CentOS stuff. Fine with me, just keep in mind. In any case I'm still waiting for @krischer's feedback about the current deb build situation for 1.1.1 .. :-P

I'm not to familiar with these new features in 3.7 -- do they really make such a big difference for us? If not, I'd probably say 3.6 to not be too strict/demanding.

There are some things related to immutability of UTCDateTime (#2072) and ResourceIdentifier (#2303) but these have already been discussed. There are also other small inconsistencies that could be corrected, but I am not thinking of anything major here.

Fine with me whatever you guys deem most appropriate here (hopefully not breaking too much old codes though?)

One thing that has always bothered me is that any of the Trace/Stream operations occur in-place by default.

Same as @krischer and @trichter, I think defaulting to in-place makes sense (for memory reasons and code would look ugly if all of a sudden it'd be st = st.xxx for all the standard processing lines), and it's just one line of .copy() if raw data is needed later in the program, so I don't see any need for change here.

I would like to see the test runner migrated to pytest (working on it in the pytestify branch) and this will probably cause some backwards incompatible changes to how tests are run, but hopefully these will be very minor.

I don't think we care too much about backwards compatibility in running tests. Only thing that matters is probably that the tests are sent in the same fashion at the end when running obspy-runtests.

We might consider switching to Numpy style docs for a more human-readable command-line experience, and because most other scientific packages use them (eg astropy, numpy, scipy, sklearn, ...).

I would not mind at all! But that is going to be one hell of a grind! If we do it we should also get rid of all the :type: specifiers or however they look in the numpy doc style and just use type annotations.

Same. I don't mind if we decide to switch, but it's a hell of a grind and somebody would have to do it. I'm not volunteering. ;-)

Also I think we should ship the pypi packages without all the test and test data - that would make them A LOT smaller. It is still possible to test these packages by just running the tests in another folder.

We could have a lazy on demand test data downloader. Basically downloading the test data only if obspy-runtests is called and the data is not there. But this is some more magic and maintenance overhead.

[lijunzh]

Some people have mentioned that they would like to have an "ObsPyLite". The rational was to make it easier to build and ship things using ObsPy. As far as I understood the problem it was never ObsPy that was the issue but more all the dependencies. Thus what I think we could do is make ObsPy usable without all dependencies available.

I am among those who write tools that rely on an ObsPyLite. It will be very helpful if ObsPy has a trim-down version that gives the flexibility on what to be included. The I/O modules are the ones that I most frequently used. I sometimes use filter/detrend etc. If there is way that I can use obspy as a dependence while not introducing other packages (things like matplotlib, basemap, future, etc), I'd love to use obspy directly as a dependence and enjoy all the automatic upstream updates.

* move everything besides numpy intro `EXTRAS_REQUIRE` in `setup.py`

This is how I use obspy now. I think it is one solution we should consider; however, it may requires some work on the dcoumentation to inform the use the dependency of each block which is not ideal for less-informed useers.

Here are the thoughts I have on this "LIte" version:

1. As @megies pointed out, this is a tradeoff between developer and user. Developer of other tools like to use obspy's core functionalities (core and I/O mostly) while not importing all other packages that are not useful to their usage. Normal users want to have everything ready once they have obspy imported. Essentially, these are two very different groups of users and may never be satisfied completely by a single product.

2. What if we offers a "kernel" of obspy that contains absolutely basic behaviors of obspy. Then, the real obspy uses it as an depedency/submodule. This way, the developers can relies on the same "kernel" the normal obspy does while not include too many packages that they never use.

3. @krischer, I like the hiearchical structure here. In most cases, I only use the Python + NumPy for I/O; sometimes, use SciPy for processing.

• Python + NumPy: Only I/O is usable. Still useful for many file conversion tasks.

• Above + lxml: XML things can be read.

• Above + SciPy: Processing becomes available

• Above + Matplotlib: Plotting is there

• Above + sqlalchemy: Other things are there.

[d-chambers]

I think we should ship the pypi packages without all the test and test data

So do you think the tests should be pulled out of obspy/obspy and put into obspy/tests ?

I would not mind adding inplace kwargs to the methods

I think this would be a great compromise. The conceptual model would then be simpler: All stream/trace methods act in-place, unless you specify inplace=False, in which case it returns a copy. It would also save a line of code. We should also make sure each method returns the instance (not sure if this is the case now) so the method calls can be chained together. It also shouldn't break any codes, which is the main consideration.

Did you think about using Black?

I love black. I would be in favor of it.

Sorry for hijacking this thread @megies :grin:

[megies]

I would not mind adding inplace kwargs to the methods

I think this would be a great compromise.

Not sure. Offering two mechanisms/ways to approach things to reach the same goal is usually not the best idea...? :-/

We should also make sure each method returns the instance (not sure if this is the case now)

Pretty much everything should. Of course some occurrences always get overlooked

[megies]

How about let's try to push 1.2.0? All hands on deck https://github.com/obspy/obspy/projects/2#card-26310701

[heavelock]

What about #2442? It would be nice to have compatibility for 3.8.

[megies]

@heavelock anything that's in the milestone/project is to be worked on or moved out from there, and obviously no release will happen before you see some release candidates posted here, so don't worry, it's on the radar ;-)

https://github.com/obspy/obspy/projects/2
https://github.com/obspy/obspy/milestone/16

[ThomasLecocq]

Ladies & Gents: time to finish your homeworks and release 1.2.0 !

[megies]

Might push out a RC1 tomorrow, I guess we'll only get real feedback on the StationXML1.1 changes through the live release anyway, so no point holding it back longer.

@krischer @QuLogic @ThomasLecocq @chad-iris
@obspy/admins
@obspy/packagers
@obspy/maintainers

[megies]

obspy-1.2.0rc1.zip
sha256sum: fd403983766e9e9e723de4a7f07d05d4bda59a822f171a6b6fc3012e51a13a8c

http://tests.obspy.org/?version=1.2.0rc1

@krischer @QuLogic @ThomasLecocq @chad-iris
@obspy/admins
@obspy/packagers
@obspy/maintainers

[barsch]

hmm couldn't find it on a quick glance - which Python versions are "officially" supported now?
3.5.x - 3.8.x ?

[megies]

@barsch 2.7 as well for this one, last release supporting py2. 3.4 is also in the setup py, but i don't think we really test it, so yes, I'd say 2.7 + 3.5-3.8

[megies]

Network tests look mostly OK, see e.g. http://tests.obspy.org/108300 (http://tests.obspy.org/?version=1.2.0rc1)

• arclink was shut down at GFZ, so fails are not surprising
• seedlink fails are due to the station we use in tests (IPGP station G.FDF) is not served right now (only a temporary outage or station removed?)
• fdsn fail for EIDA auth fails because our token apparently is EOL, personally can't be bothered to update this right now, no idea why the gave us a token with an invalidation date for testing in the first place
• syngine: tests work locally for me, and I tried some HTTP requests with success that were mentioned in the logs as failed to fetch, seems this was a temporary service outage

[megies]

@ThomasLecocq any chance you're able to debug this one Win fail in the SDS client? Otherwise I'll just skip that test on Windows for now..

http://tests.obspy.org/108333/

https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=115616&view=logs&j=5be07ae1-d8ba-5406-47b6-8e3a3a12f825&t=0d1d4714-3221-52cd-cfdb-f62a891e036b&l=7661

https://github.com/obspy/obspy/blob/1.2.0rc1/obspy/clients/filesystem/tests/test_sds.py#L227

[ThomasLecocq]

@megies trying to pull & test locally now

[ThomasLecocq]

that line fails on my machine (win64.py37)
https://github.com/obspy/obspy/blob/1.2.0rc1/obspy/clients/filesystem/sds.py#L608
regex = re.sub(FORMAT_STR_PLACEHOLDER_REGEX, r'(\w*?)', regex) + "$"

could be

regex = re.sub(FORMAT_STR_PLACEHOLDER_REGEX, r'(\\w*?)', regex) + "$"
(one extra backslash), but I don't know if that is the reason... and if that will not break pre-3.6 python.

[megies]

Thanks @ThomasLecocq, I'll just be real lax in the regex and go to .* for the whole preceding path, those multiple escapes in the bytes I'm looking at reading that file make my head spin.

[megies]

obspy-1.2.0rc2.zip

sha256sum: 6b034f43ede4554f19e2ce63bd20103f1c2bd51c083da3da67a0ebc5b0860dba

http://tests.obspy.org/?version=1.2.0rc2

@krischer @QuLogic @ThomasLecocq @chad-iris
@obspy/admins
@obspy/packagers
@obspy/maintainers

[megies]

obspy-1.2.0rc3.zip

sha256sum: b7656c758361cfe947140790c0189bd1599c805c20209f763ff9eba3bc61c1a0

http://tests.obspy.org/?version=1.2.0rc3
@obspy/admins
@obspy/packagers
@obspy/maintainers

[trichter]

When running obspy-runtests -a -r the script always fails to upload the test report for me. Is this due to the test suite or due to the server?

Ran 2218 tests in 624.273s

FAILED (failures=12, errors=11)

/home/eule/anaconda/envs/workhorse/lib/python3.7/socket.py:660: ResourceWarning: unclosed <socket.socket fd=17, family=AddressFamily.AF_INET6, type=SocketKind.SOCK_STREAM, proto=6, laddr=('2001:638:1558:e910:a91f:a274:59e4:3f35', 35268, 0, 0), raddr=('2a01:238:426b:7300:f053:c7ab:4e68:7416', 443, 0, 0)>
  self._sock = None
ResourceWarning: Enable tracemalloc to get the object allocation traceback
Error: Could not sent a test report to tests.obspy.org.
Request Entity Too Large

[megies]

I've seen that once or twice.. looks like the POST payload is too large and somehow it can't be sent? CC @barsch

[barsch]

@trichter please try again - I raised the max client upload limit to 10 MB

[trichter]

This fail gives a gigantic traceback:

======================================================================
FAIL: test_get_networks (obspy.clients.arclink.tests.test_client.ClientTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/eule/anaconda/envs/workhorse/lib/python3.7/site-packages/obspy/clients/arclink/tests/test_client.py", line 396, in test_get_networks
    self.assertIn('BW', result.keys())
AssertionError: 'BW' not found in KeysView(AttribDict({'DK':.......

Maybe we can replace the error message by a generic one. Anyway I will try again.

[trichter]

By the way, could we silence this warning by not raising it?:

 warnings.warn(msg)
./home/eule/anaconda/envs/workhorse/lib/python3.7/site-packages/obspy/taup/tau_branch.py:495: UserWarning: Resizing a TauP array inplace failed due to the existence of other references to the array, creating a new array. See Obspy #2280.

It is not really clear why the warning is raised when visiting #2280.
Also the fall-back using numpy.resize is maybe effective enough, so that a warning is not necessary?

[megies]

By the way, could we silence this warning by not raising it?:

Maybe we can replace the error message by a generic one. Anyway I will try again.

Sure, go ahead :+1:

[heavelock]

http://tests.obspy.org/108435/ Is mine. It's weird but I guess it's just some configuration difference. Most of the plots that managed to be uploaded before hitting limits on Imgur show differences in location of ticks and labels, in case of response plots there is additional line in low frequency.
Where are being stored images if I used --keep-only-failed-images argument?

[megies]

Inside the repository under e.g. obspy/core/tests/images/testrun, find /path/to/obspy -type d -name 'testrun'

[megies]

@heavelock maybe it's freetype?

This is in travis setup

134     if [[ "${PYTHON_VERSION}" == '3.7' ]]; then
135       FREETYPE="freetype"
136     else
137       FREETYPE="freetype<2.8"
138     fi

[d-chambers]

@megies I ran a few tests on rc3 and everything looks good to me.

[heavelock]

I checked for 3.6 and 3.7 with freetype installed via conda in versions according to what you cited and it didn't change anything.
What I noticed that when labels are placed differently, then the different ticks are used, ie. proper ones are on 1975, mine are on 1976.
Sometimes also labels are shifted by few pixels and ticks stay the same.

Additionally I noticed that --keep-only-failed-images did not store anything while --keep-images stored only good images and diffs.

[megies]

Sometimes also labels are shifted by few pixels and ticks stay the same.

Happens all the time when using different matplotlib versions. We try to avoid it by allowing some discrepancies but those thresholds are just pure guesswork and tests will fail again at some point. The only thing I find weird is that I see the same matplotlib version you are using in other CI builds that pass. But well, just ignore those fails.

IIRC you need both --keep-images and --keep-only-failed-images if you want to store only failed images.

[ThomasLecocq]

tests ok :)

http://tests.obspy.org/108518/ (see hostname)

[megies]

(see hostname)

:rofl:

[megies]

If anybody has some free time, i've ran some tests in docker, we should check out these fails and see if they're relevant: http://tests.obspy.org/?version=1.2.0rc3

[megies]

obspy-1.2.0rc4.zip

sha256sum: 943a194e5a40724182d3692f96e28301549bf68fbf1e6d43ce8b476d22173904

http://tests.obspy.org/?version=1.2.0rc4
@obspy/admins
@obspy/packagers
@obspy/maintainers

[ThomasLecocq]

http://tests.obspy.org/108645/ all seem OK (did the network tests too)

[megies]

We have some fails on some dists, can only look at them Wednesday though, no access to my HDD with all the docker images right now. http://tests.obspy.org/?version=1.2.0rc3

[aringler-usgs]

All the tests on node labex2 are related to arclink and seedlink issues.

I also see a lot of the failures being related to the the _read_ims10_bulletin on the debian and ubuntu tests.

The other failure is just a precision issue in the test_response.py. Could this be fixed with an almost_equal?

Is there something I could specifically look into that would be helpful?

[megies]

@aringler-usgs I'll look at the docker test fails tomorrow maybe, otherwise I think release should be ready pretty much.

[megies]

To those who worked on the release, see #2553 if you want your institution/grant/etc mentioned in release notes.

[megies]

obspy-1.2.0rc5.zip

sha256sum: 4d95298d674f84ff9a8d3991f096d5dd66b6de06063c948ab5edb64e6f9dee26

http://tests.obspy.org/?version=1.2.0rc5
@obspy/admins
@obspy/packagers
@obspy/maintainers

[megies]

obspy-1.2.0rc6.zip

sha256: 1bc6222f9ccaa9b189c216ea361c4594f3a189aa375d58750eb53b56562c63ee

http://tests.obspy.org/?version=1.2.0rc6
@obspy/admins
@obspy/packagers
@obspy/maintainers

I am fairly confident that we do not need any further RCs and that release is good to go. Had a look at network tests and most seem server side issues and just broken test cases that aren't worth fixing right now (unless somebody jumps in).

[ThomasLecocq]

py 3.7 & 3.8 seem ok on my machine...

[heavelock]

I added tests runs on my WSL configuration.

Also I tried to test on windows py3.6 and I ran into problem that obspy.io.xseed.tests.test_scripts.ScriptTestCase.test_dataless2resp_zipped was causing test runner to quit without any information, even in verbose mode. I commented out that test and it ran without any problems.

[megies]

was causing test runner to quit without any information, even in verbose mode

hmmmm, can you try to use that routine outside of test run, i.e. go to obspy/io/xseed/tests/data and run obspy-dataless2resp --zipped dataless.seed.BW_FURT? @heavelock

[megies]

In any case, I think this is as good as it gets without waiting longer for people being willing to fix super edge-case-y bugs or ancient version test fails. I'd say we should get 1.2.0 it out.

Opinions?
@obspy/admins
@obspy/packagers
@obspy/maintainers

[heavelock]

@megies

$ obspy-dataless2resp --zipped dataless.seed.BW_FURT
Found 1 files.
Parsing file dataless.seed.BW_FURT

So the stdout is as expected by test. I ran the rest of the test in a console, all asserts are fine.

[ThomasLecocq]

@megies OK for me, go !

[krischer]

Also okay for me. Also a huge amount of thanks for all the work you put into it!!

[trichter]

I agree with @krischer!

[megies]

Any volunteers for "What's new" page for 1.2.0?

exemple: https://github.com/obspy/obspy/wiki/What%27s-New-in-ObsPy-1.1

https://github.com/obspy/obspy/wiki/What%27s-New-in-ObsPy-1.2

[ThomasLecocq]

I'll attack this tomorrow midday, I'll add the content of the changelog as a first step. Could you just update the compats/machines part? I'll find the pandas or else statement on "this is the last py2 compatible release" too.

[aringler-usgs]

I made a first stab at the "What's new" page: https://github.com/aringler-usgs/obspy/wiki

Should I incorporate this into: https://github.com/obspy/obspy/wiki/What%27s-New-in-ObsPy-1.2

I wasn't sure on which notable changes should be added.

[ThomasLecocq]

@aringler-usgs sure, please do. I won't have time to put in text before 11 tomorrow (UTC+1)

[ThomasLecocq]

@aringler-usgs 1.2 is the last supporting 2.7, the next one will drop it.

[aringler-usgs]

@ThomasLecocq Thanks for pointing that out. I couldn't find the doi for this release. I also didn't know how many unique contributors. Finally, I didn't know what specific changes should be called out. I just sort of guessed. All these changes should be in: https://github.com/obspy/obspy/wiki/What%27s-New-in-ObsPy-1.2

If you think certain things should be specifically called out, then I can help with that tomorrow.

[ThomasLecocq]

I'd say all major changes (added/new) that are in the changelog

[megies]

@aringler-usgs thanks for drafting the whats new, I just reserved a zenodo DOI and will fill it in

[megies]

Abusing this comment to post an example pic for the README, see pyOpenSci/software-review/issues/16

[aringler-usgs]

@megies is there anything else you need help on to move 1.2.0 along?

[megies]

I think we're good now (once again?). I'll do a last RC and maybe run docker tests one last time tomorrow.

[megies]

obspy-1.2.0rc8.zip

SHA256: 359ee8aa83ffe363fee8323e87570bcdf7c34a4a304aae47298f1f2e194f201b

http://tests.obspy.org/?version=1.2.0rc8
@obspy/admins
@obspy/packagers
@obspy/maintainers

[ThomasLecocq]

rc8 all good for me

[ThomasLecocq]

greeeeeeeen liiiiighhhhhht :-)

[megies]

obspy-1.2.0rc9.zip

SHA256: 4b2de3902d377c42c680311c2bd7d75a369479d62ff6468c3fa5583e11f3a2a7

http://tests.obspy.org/?version=1.2.0rc9

We will just have a last look at CI and then release.

@obspy/admins
@obspy/packagers
@obspy/maintainers

[megies]

https://pypi.org/project/obspy/

[barsch]

Also I tried to test on windows py3.6 and I ran into problem that obspy.io.xseed.tests.test_scripts.ScriptTestCase.test_dataless2resp_zipped was causing test runner to quit without any information, even in verbose mode. I commented out that test and it ran without any problems.

same for me, test runner quits at two methods (the one mentioned above, and one in io.shapefile) without any error message, really strange - had to exclude io.xseed and io.shapefile and run them separately which worked:
http://tests.obspy.org/?node=Turtle&version=1.2.0

anyway, all packages for Windows are uploaded to pypi:
https://pypi.org/project/obspy/#files

[megies]

hmm.. must have overlooked that issue about running the tests.. ah well

[trichter]

* ~conda packages for Linux 32bit via https://github.com/obspy/obspy/tree/master/misc/installer/anaconda and distributed at https://anaconda.org/obspy/obspy/files~ do we still need this??

I think we don't need these installers anymore. For myself it is good enough to install dependencies with conda-forge and obspy with pip... and probably there at not many other people using 10 years old laptops anymore.

[megies]

Released 1.2.1 to get around that setuptools backwards incompatibility quickly see #2578