EOL schedule for GPyOpt?

[ekalosak]

In light of emukit's development and pervasive suggestions to switch, would it make sense to make a schedule for gracefully EOL-ing GPyOpt?

Benefits:

• new projects are systematically redirected there
• existing projects have notification and reliable expectations of the timeline

[apaleyes]

Oh, hope we didn't come across as too pervasive!

This opens up a discussion we had internally with @javiergonzalezh before. Basically we recommend emukit to those who want to extend gpyopt in non-trivial way, because we feel gpyopt reached limitations of its design. Say adding multi-output GPs (for multi-fidelity problems) or using models other than GPs - all of that would be a real pain in gpyopt, but is very natural in emukit.

That said, gpyopt is probably more mature, certainly as far as the community around it goes. So we wanted to announce EOL for gpyopt at some point, but then decided that people may just move to emukit organically. gpyopt userbase is hundreds, maybe thousands of researches, and it is oblivious to imagine they all just move to a new tool overnight. That is the primary reason why we haven't move to EOL stage yet.

On the other hand, we obviously don't have the capacity to develop gpyopt further, so EOL for it seems inevitable at this point.

I am going to tag other folks involved to hear their thoughts: @javiergonzalezh @zhenwendai @lawrennd

[ekalosak]

^ meant pervasive only as "wide-spread" with none of the negative connotation, sorry about that.

[pavel-rev]

Hi all, I plan to use this package in a commercial project. what is the process? Or this is dying package?

[lawrennd]

Thanks for retriggering this thread. You can use it directly in a commercial project because it's BSD 3 clause licensed.

There's a lot of functionality in Emukit, which is a general emulation package. But it's not a direct replacement. Can you share something about your usecase and maybe @apaleyes could comment.

[pavel-rev]

It is expensive to run objective function (let's call it a numerical simulation run). Variables (~10, 30 in number in worst case) are mostly discrete, with the same search space (Di in 0 to 100% with 5% step), with constraints imposed (variable values should monotonically decline, i.e. Di>=Di+1). We are in concept phase. I did a little research on existing packages for Bayesian Optimization with GPs and GPyOpt looks good. I already made one basic test run, and it showed good results. The initial parameter space setup took infinite time to pick proper anchor points, so I passed a pre-computed search space directly to sample from (we assume all search space will be available in most cases, at least part of it in worst case scenarios). For now i have own cloned repo on premises, but i was suggested that I submit a pull request through GitHub to this open source project to simplify future maintenance.