roadmap, version 1.0, dropping Python 2 support, etc

[newville]

(Yes, we could use a mailing list or wiki for this discussion, but I think the Issues conversation style is OK here too... hope that's OK with everyone else. I'd be OK with moving this to a wiki page.)

Over at #527, @reneeotten and I started the discussion of releasing 0.9.13, version 1.0, which scipy versions to support, when to drop support for Python 2, etc. Those are probably each slightly different topics, but close to each other. I think the basic issues are:

1. release 0.9.13 soon (before or around April 1), with approximately "current master". I'm not sure we have a solution for Parameters do not get passed properly when performing a re-fit with the ModelResult.fit() method. #530, and I'm not sure about [WIP] Add html_repr's #524.

2. when to change requirements for scipy versions? Traditionally, we've used "2 years old" as guidance for minimal scipy version (which would be 0.19), but as we approach 1.0 and dropping Python 2, those can be relaxed. And the addition of new algorithms in SciPy v1.2 #527 needs 1.2.0.

3. when to tag 1.0, and what that means? It should be API stability, but it's also an opportunity to drop Python2 support, clean up dependency requirements (including minimal versions) or re-organize docs, examples, tests, etc. Personally, I think the API is stable and that we'renear feature-complete enough for 1.0. I'd say we aim for the summer, but no firm timeline.

4. when to drop Python2? I think this code is actually pretty clean for Py2 v Py3 (there's not even much use of six) and could support both for awhile without much trouble. But there is not much incentive to need Py3, and it would be useful to rely on Py3-only features like dicts being ordered and other simpler constructs. It would also allow unicode variable/parameter names (which might be more trouble than it's worth, but worth looking into). I'd also say we aim for the summer, but no firm timeline.

FWIW, I have no preference if we drop Py2 at 1.0 or at 1.1 or if we require scipy 1.2 at 1.0 or 1.1 but I would sort of prefer that in a year or so, lmfit is at or past 1.0, and is Py3 + scipy 1.2.something only.

Was there anything else I missed? Comments? Suggestions? Concerns?

[newville]

I propose that we merge #546 and tag that as 0.9.13, in a couple of days (end of the week). That leaves #545 unmerged and does not address the reported issue of weird behavior with starting values near 0. Is that OK?

[reneeotten]

I propose that we merge #546 and tag that as 0.9.13, in a couple of days (end of the week). That leaves #545 unmerged and does not address the reported issue of weird behavior with starting values near 0. Is that OK?

That sounds like a plan! I will not have figured out the shgo and dual_annealing stuff before that, so let's postpone that to the next minor release.

As I said in the other thread, I would be in favor of having a last "fully-featured' PY27 release, in which we require scipy LTS version (1.2.x) and have all algorithms supported (including shgo and dual_annealing). Additionally, we should move the test-suite fully to pytest and increase the test coverage (the recent addition of coverage is a good help for that). That might be a good point to release 1.0 and have that as the final PY27 supported version (in case we find terrible bugs those can be potentially fixed a 1.0.x minor version); moving forward from 1.1 we can go PY3-only.
Finally, there was a topic on the mailinglist about this a few years back, which has some points that we could (re)consider.

[newville]

@reneeotten

That sounds like a plan! I will not have figured out the shgo and dual_annealing stuff before that, so let's postpone that to the next minor release.

OK.

As I said in the other thread, I would be in favor of having a last "fully-featured' PY27 release, in which we require scipy LTS version (1.2.x) and have all algorithms supported (including shgo and dual_annealing). Additionally, we should move the test-suite fully to pytest and increase the test coverage (the recent addition of coverage is a good help for that). That might be a good point to release 1.0 and have that as the final PY27 supported version (in case we find terrible bugs those can be potentially fixed a 1.0.x minor version); moving forward from 1.1 we can go PY3-only.

That plan for "what should the final Py27 version support" is fine with me: we make a version that works for Py27 and scipy 1.2.x before dropping P27 support. It is OK to call that final-Py27 version 0.9.1* (let's hope 0.9.14), and then have version 1.0 require Py36 or higher? That would be my preference (as we could then drop six and rely on dicts being ordered as well as other nice features of Py36+).

For testing, I think we're only using pytest and unittest (which in standard lib) and numpy.testing, but not nose (even though one file is still called test_nose.py). I don't have objections to the tests that use
unittest or numpy.testing... is this OK with you?

Finally, there was a topic on the mailinglist about this a few years back, which has some points that we could (re)consider.

Yes good point. From my perspective I would summarize that discussion as

1. a proposed change of Parameter min/max attributes to lower_bound, upper_bound (or some other name), properties.

I don't see a huge implementation benefit for the implementation, but a property of lower_bound and upper_bound (or maybe minval and maxval?) could be useful. No strong opinion.

2. Is it worth transferring from asteval to numexpr?

I think it would probably not be easier. I could be persuaded it's a good idea, but I'm eager to do this myself.

3. can we clean up the "fcn_args / args" stuff and make the optional arguments to the various solvers more consistent and better? For example, having a uniform way of spelling "maximum number of iterations".

This is probably worth looking into. Sort of a meta-question would be: how closely should we follow an re-expose the scipy API. Currently we sort of err on the side of following their API including its oddities. We could try to clean this up.

2. can we make ModelResult and MinimizerResult more consistent, possibly with "ModelResult has a MinimizerResult"?

In fact #546 sort of reminds me that ModeResult inheritingfrom MinimizerResult can be confusing. I think this is worth looking at.

3. how can we cope with all the options of scipy.optimize.least_squares() in a way that makes sense?

I think this is similar to "how closely do we follow the scipy API". I'm not sure we want to tackle this completely. Maybe we allow an evolution away from "very close to scipy" during the 1.* series?

[newville]

@reneeotten with #556 and soon #565 merged and a host of small fixes, we're probably ready to consider releasing 0.9.14. And with #570, and with 2020 fast approaching, I think it's time to revive the conversation about dropping Py27 support and aiming for version 1.0.

As an updated starting point (suggestions welcome -- I'm probably forgetting something important!), I would propose that we release 0.9.14 soon (perhaps Aug 1?) and continue making small fixes through the fall. We can aim for 0.9.15 around Oct 1 that would be the final version to support Py27 but that
requires scipy 1.2.

At that time we also release 1.0 that is Py36+, requires 1.2 and can make use of many Py36+-only features, including:

1. drop six
2. use inspect.signature.
3. really on dictionaries being ordered.

but that also leaves 1.0 and 0.9.15 pretty close in usage and interface.

That gives us a target (0.9.15) and realistic time frame to do some cleanups like removing nose and add more uniform keywords for common fit_kws concepts (like "max iterations" and "fitting tolerance") so that fit_kws can become even less necessary, but also a firm-ish target: Py27 development will end in late 2019.

[reneeotten]

@newville this sounds like a good plan to me!

Issue #570 sounds fairly straightforward to resolve (but I haven't actually looked how different the inspect.signature interface is...). Would you want to include that in 0.9.14 (or if it turns out to be more time-consuming in 0.9.15) as well by adding the backport for Python 2.7 or only add that to version 1.0?

[newville]

@reneeotten Yeah, I think that addressing #570 and using inspect.signature would not be too hard. It's a big change from argspec, but it looks straightforward and is encapsulated in ~10 lines of current code. It's also relatively "clear" in what it should do and we have lots of tests of Model (at least, using unwrapped functions) that will break immediately if we get something wrong.

So, sure we could (try to) add that for 0.9.14 (~Aug 1), adding a dependence on Funcsigs for Python2, and then plan on dropping that later in the fall.

[reneeotten]

Additionally, working towards a 1.0-release I think we should review/update the examples (plus give them a more prominent place on the website) as well as re-working how code/examples are added to the documentation.

I have some ideas for both of them (i.e., using sphinx-gallery and jupyter-sphinx) and will open PRs for both of these sometime this week. These will be both work-in-progress PRs and would certainly benefit from others helping out; for example, we might want to actually write some good, documented examples to show how to do certain common things with lmfit.

[newville]

@reneeotten Yes, that would be great!

A bit more of a Users Guide -- worked examples with even a small bit of explanatory text -- would also probably go a long way in answering the most common categories of questions and maybe inspire people to try new and interesting things.

[newville]

@reneeotten I tagged 0.9.14rc1. Even if the docs are being tweaked, I think the code captures all the addition of shgo and dual_annealing and the recent bugfixes. I think this is very close to ready for a final release, but let me know if you think we've forgotten anything.

[reneeotten]

@newville I think it's indeed pretty much done. I've left a few comments on your PR, which then should be ready to merge. I think after that merge and doing the easy fix for issue #584, we should be good to go. So what about we fix these two things and then release 0.9.14? I don't think there is anything else left, but if you want to tag another rc and release after the weekend that would be fine as well. I am not sure though it that would really benefit anyone, as release candidates are only really useful if you give people time to actually test things and report issues...

[newville]

@reneeotten Yes, I agree. I'll merge #583 and then make a PR to address #584.

I propose that we plan to release 0.9.15 on 28-Aug or 29-Aug. That still gives us time to merge the two PRs in question without feeling too rushed.

[newville]

@reneeotten FWIW, I think that 0.9.14 is now completely ready for release, and with a pretty huge set of improvements made over the spring and summer. If you or anyone else here has reservations about tagging the current master as 0.9.14, let me know. Otherwise, I'll plan on tagging and releasing two days from now: 29-Aug.

[newville]

@reneeotten @Tillsten sort of as a meta-Issue for the release of 0.9.15 and 1.0. I think we should be ready and able to release 0.9.15 and 1.0 before the end of the year.

I believe we should include #594, #595, #596, and #598 in 0.9.15 and 1.0 . It would be good to at least partially address the max_iterations part of #332.

I'll take ownership of (and fix) #594 and for #332 (hoping that @luriomer can help). It seems that @reneeotten has #595 under control and @reneeotten and @Tillsten are perfecting #596 and #598.

I'll also plan on making a pre-1.0 branch in a few weeks (maybe after merging a few of the PRs), and make that branchPython 3.5+ only (which I think is actually not very much work).

Does this all seem reasonable and a (currently) complete set of goals? I think the docs and gallery are in good shape, but is there anything in the docs, examples, or code that should be addressed for 0.9.15 and 1.0?

[reneeotten]

@newville yes, that sounds like a good plan! I don't think there is anything regarding docs + gallery that needs changes right now. I am still planning to continue on the test-suite, but that shouldn't hold up anything as it might take more time to finalize.

I would prefer though to make a 0.9.x branch after we have merged a few of the PRs you listed. We can release the last PY27 version from that branch and continue to work on the newer, PY3-only version on the master branch.

[newville]

@reneeotten Good idea, I agree to make a 0.9 branch and then leave that to wither....

[newville]

@reneeotten @Tillsten OK, we are close to running out of time for 0.9.15 and 1.0 and dropping support for Python2. This is by far my highest priority for lmfit. I'm low on bandwidth and feeling over-extended on many fronts. Version 1.0 will be released before the end of the year. After that, I make no promises about support or further development. I would like to be able to do this but am not sure I will be able to do so effectively.

There appears to have been no action on #332. I might do this on my own. #600 (replacing #594) has been very slow, and support for emcee seems tenuous at best. #604 seems to have been stalled by a styling question. These PRs either need to be merged soon or not included in 0.9.15 and 1.0.

So, if not already merged, I will merge #600 and #604 by 25-Nov. If needed, I will clean up the master branch after that.

• Version 0.9.15rc1 will be tagged by 29-Nov. I may or may not address maxfev and maxiter should be supported for all methods, and uniformly #332 by that time.
• Version 0.9.15 will be released by 9-Dec.
• Version 1.0 will be released by 16-Dec, dropping Python 2 support.

[luriomer]

@newville I'm sorry for the delay in #332, I have a lot going on lately. I'm still planning to do this, just not sure exactly when.

[Tillsten]

@newville No worrys, I think the package is in quite good shape. There is only really one main feature which I think is still missing, which is the fitting mupltile models while sharing parameters. But we are still fine without that. We could think about publication to JOSS or something simliar for the 1.0 release if you are intrested.

[luriomer]

I personally am very interested, just need to finish a current publication of my own and I'll join you :)

[BishopWolf]

Dropping Python2 support means also that all your dependencies shall also be python3. I have faced a problem with uncertainties package which is written in python2 and relies on 2to3 actions to be converted to python3. This is not automatically done in pure python3 systems where no 2to3 executable exists (this will be deprecated also). Please make sure that the final product has dropped the python2 dependencies.

[newville]

@BishopWolf Well, we support Python3 now. We're just aiming to drop Python2 support. We don't have any python2 dependencies. We actually only have a couple places where six is used. So it will not be hard to drop Python2 support.

I agree that uncertainties has an issue with Python3 support by relying on 2to3. So far it has worked OK. I imagine that when it stops working to use 2to3 that it will get fixed or the project will fork to a Python3-compatible uncertainties package.

[newville]

@reneeotten, @Tillsten, all: I think 0.9.15rc1 has no problems. Any objections as just promoting that to be 0.9.15 "final" in the next few days?

[reneeotten]

@reneeotten, @Tillsten, all: I think 0.9.15rc1 has no problems. Any objections as just promoting that to be 0.9.15 "final" in the next few days?

I don't think either that it has (major) issues, but also have no idea how many people actually test pre-release versions especially given that this one was just released 3 days ago. Having said that: yes, it's fine with me to release this as 0.9.15 final.

After that, we should branch-off a 0.9 or python2 branch from master. I will open a PR in the next few days with a starting point to become PY3-only. We can just keep adding commits to that PR until everything is cleaned-up and everyone is happy.

[newville]

@reneeotten Yeah, I guess that's a fair reading of the short rc1 time. I tested my downstream codes (and modified for the upcoming API changes) for 0.9.15, but I don't expect everyone to do that. I'll plan to release 0.9.15 this weekend, but it might be Monday.

FWIW, the v0.9.15 branch is currently identical to master. We could just leave that unmerged but undeleted and make master Python3 only. I don't have a real preference on that. Whatever we call bcb23dc, that will be "last commit that supports Python2".

[reneeotten]

FWIW, the v0.9.15 branch is currently identical to master. We could just leave that unmerged but undeleted and make master Python3 only. I don't have a real preference on that. Whatever we call bcb23dc, that will be "last commit that supports Python2".

@newville true... However, I did clean-up branches that were merged already yesterday or so and already removed the v0.9.15 branch. So either way, we'll have to make a new branch - I would prefer python2 as a name, but am fine with 0.9.15 as well ;) I agree with continuing on master as PY3-only.

[newville]

@reneeotten OK, thanks. Tagging current master as "python2" is fine with me.