search

JuliaWeb / URIParser.jl

Uniform Resource Identifier (URI) parser in Julia
Other
17 stars 29 forks source link

Tag a v1.0.0 version #64

Open davidanthoff opened 5 years ago

davidanthoff commented 5 years ago

Could we tag a version 1.0.0?

That would make it much easier for packages that depend on this one here to use semver compat bounds in Project.toml. The problem is that pre 1.0.0, every minor update is considered breaking, whereas starting with 1.0.0 one can use the full semver semantics, which make everything easier.

Also, it seems that this package is so widely used with the current API, that one might as well declare what we have as stable and done, right?

ararslan commented 5 years ago

I didn't even think this package was still used. Most URI parsing I've seen done just uses what's in HTTP.jl.

davidanthoff commented 5 years ago

I'm using it a lot: it is small, does what it is supposed to do, doesn't come with many dependencies and doesn't have code churn that I need to deal with. Perfect for our use cases. I appreciate HTTP.jl, but I shouldn't have to take a dependency on such a big package if all I want to do is parse a URI.

Should I open a PR that migrates this to Project.toml and increases the version to 1.0.0?

davidanthoff commented 5 years ago

So, for example the whole VS Code extension uses this a lot. And we couldn't use HTTP.jl because we can't take dependencies that have a deps/build.jl script in it, which one of the upstream deps of HTTP.jl brings along.

ararslan commented 5 years ago

HTTP's URI parsing code has seen more recent development than this has, so I think that should be migrated here, then HTTP can just take a dependency on this package to do URI parsing.

quinnj commented 5 years ago

I've talked w/ @StefanKarpinski a bit about being able to register a new package from the same repo of a "parent" repo; in this case, the URIs submode of HTTP.jl is completely self-contained and could standalone as its own package.

davidanthoff commented 5 years ago

Is the URI code in HTTP.jl backwards compatible with the API provided by URIParser.jl? In that case I would be in favor of just moving the code from HTTP.jl into URIParser.jl. If not, I would think the best solution would be to create a new URIs.jl package.

I'm not a fan of something like having the code live in the HTTP.jl repo, but exposing it as a different repo. None of the tooling supports this, it would confuse the heck out of people that want to contribute to the package (everyone is used to the workflow of one repo per package) and what exactly would be gained? Wouldn't it be by far the easiest option to simply create a URIs.jl package the normal way?

quinnj commented 5 years ago

I'm not a fan of something like having the code live in the HTTP.jl repo, but exposing it as a different repo. None of the tooling supports this, it would confuse the heck out of people that want to contribute to the package (everyone is used to the workflow of one repo per package) and what exactly would be gained? Wouldn't it be by far the easiest option to simply create a URIs.jl package the normal way?

The tooling is indeed meant to support this (though doesn't currently). I also would argue that it would be less confusing for users w/ issues or would-be contributors. Previously, a user/contributor had to understand the nuance of the webstack and know whether an issue should be reported to Requests.jl, HttpServer.jl, URIParsers.jl, HttpCommon.jl, etc. That led to significant duplication of issues and was a main driver behind consolidating the webstack code in HTTP.jl.

Another fact contributing is that there frankly aren't a ton of web contributors, so having things consolidated and centralized at least help those few of us who do contribute to manage things.

Now, all that said, I do think it would still be worth splitting out URIs.jl and Servers.jl into their own, stand-alone packages/repos separate from HTTP.jl. They represent distinct enough modules that I think the separate makes sense.

davidanthoff commented 5 years ago

I don't have an opinion about the rest of HTTP.jl, but it seems for the URI type we are then all in agreement that it should go into its own package in its own repo?

What are arguments for starting a new URIs.jl repo vs. continuing to use URIParser.jl?

quinnj commented 5 years ago

I think I'm in favor starting a new repo, marking URIParser.jl as deprecated, and letting people switch over naturally; though it takes a bit of time to get people to switch over, I feel like it's the least disruptive.

davidanthoff commented 4 years ago

Bump, it would still be wonderful if we could move the URI stuff out of HTTP.jl and into an URIs.jl package. I took a quick look and I think it is a bit too intertwined with other stuff in HTTP.jl for me to do this, but for someone familiar with the HTTP.jl codebase this might all be fairly simple?

I think naming the new package URIs.jl, as @quinnj suggested above, is the best option. And then hopefully it can move into the stdlib at some point.