mahf-opt / mahf

A framework for modular construction and evaluation of metaheuristics.
GNU General Public License v3.0
10 stars 0 forks source link

Prepare MAHF for crates.io #173

Closed Saethox closed 1 year ago

Saethox commented 1 year ago

I'm making this a draft for now, so we can discuss the design decisions before anything is merged. This is a PR that emerged from some experimental changes I wanted to try out and have integrated before we publish on crates.io, and it subsequently got somewhat out of control (the line diff scares me).

In general, I'm pretty happy with how it turned out, but there is still much work to do apart from all of this.

Documentation

This PR should include

I just didn't want to spend time documenting stuff we might change, so I put it off until now. It should definitely be part of this PR though.

Rustfmt

I added a rustfmt.toml with the options mentioned in #164, and adapted the ci.yml to use nighly rustfmt, because these options are nightly. clippy, check, and test are still performed on stable just like before. I just can't go back to the old imports after I have seen the beauty of what nightly rustfmt is capable of.

Changes

Problems

State

Components and Conditions

Logging

Other

HeleNoir commented 1 year ago

While this sounds really good in general, would it be possible to split this PR in smaller ones, each focussed on a specific aspect? Reviewing everything as a whole is a bit overwhelming and particularly prone to errors. Generally, we need a better PR workflow.

If its not (easily) possible, we can leave the PR as is, but next time, smaller ones would be better.

luleyleo commented 1 year ago

@Saethox how much work would it be to split this up? Or at least move everything, where it is convenient, into separate PRs. For example, removing the old problem modules could easily be separated, right?

Saethox commented 1 year ago

While this sounds really good in general, would it be possible to split this PR in smaller ones, each focussed on a specific aspect? Reviewing everything as a whole is a bit overwhelming and particularly prone to errors. Generally, we need a better PR workflow.

I know, right 🙈. I was a little much too focused on getting it all to work together.

how much work would it be to split this up? Or at least move everything, where it is convenient, into separate PRs. For example, removing the old problem modules could easily be separated, right?

Splitting the problems is easily done, the other changes are more cumbersome. I'm in no real hurry to merge this (maybe before GECCO), so I could probably split this PR into three/four incremental PRs:

Depending on how we want to handle the problem dependencies (mahf-tsplib -> mahf, mahf -> mahf-tsplib, mahf-problems -> mahf-tsplib -> mahf), the problem changes could be moved into the mahf-problems repo at this point.

We can then just use this draft as a proof that all of the concepts do work together, so I guess that's nice to know 🤷‍♂️.

HeleNoir commented 1 year ago

I think 3 or 4 PRs would be okay.

I'm in no real hurry to merge this (maybe before GECCO)

Well, I would prefer as soon as possible, but before GECCO would be okay. I have to start implementing #75 and I also need to play around with the logging a bit to get data for the evaluation (so I can finally implement it completely) and I fear if I start before this PR is done, I will cause additional problems.

Saethox commented 1 year ago

I have to start implementing https://github.com/mahf-opt/mahf/issues/75

That's not really a problem, porting components to the new state management and returning a result instead of panicking is done in a few minutes, It's not like the functionality of the components gets any different through this, especially for specialized operators.

I also need to play around with the logging a bit to get data for the evaluation

Again, the general concept of logging is not that different, it's just more flexible than before. The log format is also exactly the same.

Saethox commented 1 year ago

Obsolete with #176 and #178