fsprojects / FSharp.Data

F# Data: Library for Data Access
https://fsprojects.github.io/FSharp.Data
Other
806 stars 288 forks source link

Why are the core features (`CommonRuntime` folder) implemented in the Http project? #1468

Closed mlaily closed 1 year ago

mlaily commented 1 year ago

It looks like an oversight made during the split in multiple projects?

https://github.com/fsprojects/FSharp.Data/blob/main/src/FSharp.Data.Http/FSharp.Data.Http.fsproj#L15-L22

It would seem more logical for these files to be in FSharp.Data.DesignTime, or in a new dedicated Core project.

What do you think?

cartermp commented 1 year ago

Hmm, yeah, offhand I'd say these don't have any business being in that project, since it's just HTTP utilities really.

dsyme commented 1 year ago

Part of this is related to whether we spilt the type providers out.

Until we do that and decide on naming for that, I felt it wasn't much point in having a FSharp.Data.Runtime.Utilties.fsproj or something. They had to go somewhere, so they ended up in the one project that everything else already depended on.

mlaily commented 1 year ago

Hmm ok, I see. Too bad it's called *.Http then^^'

I was very surprised when debugging the providers from a script by referencing the dlls explicitly and it didn't work until I referenced FSharp.Data.Http.dll even though my code was not supposed to depend on anything http related.

Maybe this is only really an issue for debugging like this though...

Do you see the current situation as something that will have to change before the next release, or do you plan to keep it like that until the providers are split out? (if it ever happens)

Would an attempt to move the types necessary for the providers into the FSharp.Data project be welcome? (or maybe this project is supposed to stay an empty shell?)

I'm willing to help but I don't know in which direction we want to go...

dsyme commented 1 year ago

FSharp.Data should remain an empty shell, that was kind of the point of splitting things up.

I think you could try moving them to a new FSharp.Data.Runtime.Utilties. I'd have no direct problem with that - however there may be devil in the detail (e.g. if the Http part depends on some of them)

mlaily commented 1 year ago

Ok, thanks.

I took a look and maybe you already had it in mind, but it seems the first difficulty is that most if not all the providers depend on the http implementation (if only for their Load method accepting a uri).

Extracting a new Runtime.Utilities project from the current http project would probably result in the Http project containing only Http.fs.
(Http.fs is the first file in the http project, and the project doesn't depend on any other project, so I doubt the Http part depends on anything)

Would simply renaming the FSharp.Data.Http project to FSharp.Data.Runtime.Utilities or anything else be acceptable instead of creating a new project? Or do you feel the http part deserves its own project in any case?

dsyme commented 1 year ago

Yes people want the Http part alone - part of the point in splitting things out was to make that available as a nuger package