Hopac / Hopac

http://hopac.github.io/Hopac/Hopac.html

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

FSharp.Core 5.0 support

vilinski opened this issue · comments

last version of Hopac (0.4.1) depends on FSharp.Core (>= 4.5.0 && < 5.0.0)
The command output of paket outdated in the project using Hopac looks like this:

  Group: Main
    * FSharp.Core 4.7.2 -> 5.0.0
    * Hopac 0.4.1 -> 0.3.23

AFAIK Hopac should be compatible with FSharp.Core 5.0.0 also, so the version restriction needs to be relaxed

Thanks for notifying.

I have tried to make a PR for this, but I'm on Windows and am unable to build (#200).

I'm eager to update to F# 5, but am blocked by Hopac though another central dependency. I hope this can be fixed soon, since it's listed as an easy task! @haf, do you think you could just do this and push a new version? Given the build problems on Windows, it might be a while before anybody else picks this up...

Interesting, because I'm on macos and can't build too - no mono installed :)

Also looked into it. It's not that easy as increase a version. There is some work and are also some things to decide:

  • at first, maybe it's already a good idea to abandon full net471 and let netstandard2.0 only? In one week even netstandard is obsolete.
  • cli tools, including paket are not uptodate too
  • global.json could also point to the latest 3.1
  • ToDo example project is probably not upgradeable. At least it has old project format
  • FsiRefGen could be replaced with fsdocs tool

It's not that easy as increase a version. There is some work and are also some things to decide:

I'm certainly no expert on this repo (I haven't looked at it before today), but AFAIK, literally the only thing needed to solve this issue is to produce a NuGet package that doesn't have the < 5.0.0 requirement on FSharp.Core. (If the existing package had relaxed the dependency, it'd work fine, I think. Perhaps the NuGet package could even be manually downloaded, edited and pushed - not that I necessarily would encourage that, I'm just saying that I believe the existing package works fine, it's just the metadata that needs updating.) Everything else, including everything in your list @vilinski, are "optional extras" that could also be done later, if desired.

Just mentioning this in case your list of changes means FSharp.Core 5 support in Hopac will be significantly delayed. If so, I'd argue it's better to just release a package with a relaxed FSharp.Core dependency, and worry about everything else later, because it's not as critical.

There’s no need to feel like the build system cannot be changed. Having a single sln file is just fine with me. Make it work then make it beautiful

Maybe a build like https://github.com/haf/expecto would be great — or even without paket if that makes it easier to package. There's a branch feature/netcoreapp2.2 that might interest someone interested in upgrading as well; I've done most of the work to support ValueTask there.

Looks good for my naive eyes. Is there something not ready or why is #194 not released since then?

Because it probably has another 2 hours of coding and testing; mostly just filling out the API similar to how it's for Task. And because I haven't been able to secure funding for this sort of work, so it's on a free time basis right now, of which there is not much.

Since I can't contribute due to failing builds, and we're blocked from F# 5 by this, I'm considering changing my JSON:API framework Felicity to not depend on Hopac but just use task instead. It's far from ideal, So I'm just wondering if anyone is working on a fix or planning on fixing this soon.

Am I right in that the only thing that is needed, is removing ~> LOCKED:Minor from these lines?

framework: net471
FSharp.Core ~> LOCKED:Minor
framework: netstandard2.0
FSharp.Core ~> LOCKED:Minor

Like this:

    framework: net471    
-        FSharp.Core ~> LOCKED:Minor 
+        FSharp.Core
    framework: netstandard2.0
-        FSharp.Core ~> LOCKED:Minor 
+       FSharp.Core

And then just to run the release pipeline, whatever that is?

I really do hate to be a bother, but if it is actually that simple, is there any chance that you @haf as the maintainer of this repo could make this change, bump the version and release?

The way I read #200, this repo is set up for build only on Linux and not Windows, and building on Windows requires cygwin and custom shell scripts. I've had troubles with my environment after Cygwin stuff in the past and don't want to get burned again and possibly have to reinstall. In general, it seems that a "proper" build on Windows is an undertaking that is too massive for me. But please let me know if I'm wrong.

If, on the other hand, the build/release pipeline of this project works fine, then of course I can submit a PR with the change I mentioned above. But I can't find any contribution guidelines for this repo, so I have no idea what else is required to release; where release notes are that must be updated and where version numbers are that must be bumped, or what triggers a release (I guess you need to do that yourself?). If you can enlighten me on this, I can create a naïve PR and hope it builds in the CI pipeline, and we can fix this. :)

Thanks, I have made an attempt in #207. Hopefully it's at least a start.

Closing; if there's still work to be done, please send PR:s. I've tagged the current master as v0.5.