Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
mlaily opened this issue Dec 4, 2022 · 6 comments · Fixed by #1475
Closed

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

mlaily opened this issue Dec 4, 2022 · 6 comments · Fixed by #1475

Comments

@mlaily
Copy link
Contributor

mlaily commented Dec 4, 2022

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
Copy link
Collaborator

cartermp commented Dec 7, 2022

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

@dsyme
Copy link
Contributor

dsyme commented Jan 6, 2023

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
Copy link
Contributor Author

mlaily commented Jan 6, 2023

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
Copy link
Contributor

dsyme commented Jan 6, 2023

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
Copy link
Contributor Author

mlaily commented Jan 6, 2023

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
Copy link
Contributor

dsyme commented Jan 17, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment