Move to core?

Question

Move to core?

natefaubion opened this issue 8 years ago · 14 comments

natefaubion commented 8 years ago

IMO, this is an essential library that I think should belong in core. Would you be open to donating it?

/cc @hdgarrood @garyb @LiamGoodacre

Answer 1 · 2017-12-19T15:47:32.000Z

Absolutely. Let me know what needs to be done in order to realize this.

Answer 2 · 2017-12-20T00:51:31.000Z

Actually, on second thoughts, adding libraries to core complicates releases, and this library seems to be doing ok where it is now; unless we ever want to depend on this library in any other core library, I think it might be best to leave this as it is.

Answer 3 · 2020-10-14T01:27:01.000Z

Past me is talking nonsense, this should clearly be in core. I will poke around a bit and propose a way forward.

Answer 4 · 2020-10-14T01:30:53.000Z

The only barrier I can see is that core libraries ought not to depend on non-core libraries, even for their devDependencies - this rules out test-unit. However I think it should be relatively easy to rewrite the tests to depend on assert instead. It will admittedly make the test output worse, but I imagine these tests aren't failing (or even being run) very often anyway.

Answer 5 · 2020-10-22T13:31:41.000Z

I've submitted #10 to migrate tests to assert. What else do we need to do to move this to core? Or is it just lack of time to do the work?

Answer 6 · 2020-10-22T13:44:07.000Z

IIRC you can’t transfer repos to an org unless you have the ability to create repos in that org, so I’d suggest:

@sharkdp transfers this repo to a core team member’s personal account (I’m happy to do this)
that core team member transfers the repo to the purescript org,
that core team member adds @sharkdp with admin access to the purescript-numbers repo in its new location.

I think this can happen either before or after #10 is merged.

Answer 7 · 2020-10-22T14:17:13.000Z

Happy to do this, but will take a few days, as I am currently on vacation

Answer 8 · 2020-10-22T16:14:10.000Z

Great! No rush at all :)

Answer 9 · 2020-10-23T17:08:51.000Z

I requested the move to your account.

I'd be glad if you could handle #10 once the repo has been moved (I would hope that the PR will be migrated).

I don't need admin access on the new repository.

Maybe one last thing from my side: I'm not sure if (all of) Data.Number.Approximate should go into core. It seems a bit too "opinionated" for a core library.

Answer 10 · 2020-10-23T18:47:02.000Z

Thanks! I see what you mean about it being opinionated, but at the same time I think the API it provides does make sense and I think changing or removing it would likely cause more of a problem for people who are using that module, so I'm happy to leave it as-is personally.

Answer 11 · 2020-10-23T19:13:09.000Z

Thanks sharkdp! (not tagging you in case you're still on vacation)

Can this issue be closed then? URL shows that it's under purescript now.

I think changing or removing it would likely cause more of a problem for people who are using that module, so I'm happy to leave it as-is personally.

Would we ever consider porting just that content to its own separate repo, even if it's still in core? Or should that be reconsidered in the future when we do breaking changes again so that we can get v0.14.0 sooner?

Answer 12 · 2020-10-23T19:59:34.000Z

Yes, thanks, I’ll close it now.

We can consider what to do with Data.Number.Approximate now, but for me it’s not a question of now versus later, I just think it’s a useful API, and in my view it’s not really that opinionated, so I don’t think including it in core should be considered a problem. Comparing numbers is a pretty common thing to want to do.

Answer 13 · 2020-10-23T20:00:51.000Z

To me the only thing opinionated about it is unicode operators, which we have a policy against in core.

Answer 14 · 2020-10-23T20:03:06.000Z

Yeah, although for that I wouldn’t mind making an exception in this case, since removing them would be a breaking change.