Integrating network-uri-static into network-uri

[ezrakilty]

Hello: On the network-uri bug tracker there was a request to integrate Network.URI.Static into it. I played around with it and it seems to work, so I wondered if you had any objection.

If we go ahead, we'd have to figure out how to handle maintenance of the Static module. I am not too adept at Template Haskell, so I would be interested to have your help.

Please let me know your thoughts!

[snakamura]

@ezrakilty That would be great if you integrate Network.URI.Static, and I'll help integrate it into network-uri. I've taken a look at the original discussion, and there seems no difficulties but I'm not sure how I can do on network-uri-static.

Am I right that you're going to follow these steps?

1. Move the Lift instances to Network.URI
2. Move the other part of Network.URI.Static to network-uri
3. Bump a version of network-uri
4. Set the upper bound version of network-uri to network-uri-static so that it cannot be installed with a newer version of network-uri, or make network-uri-static export nothing if network-uri is newer than the specific version

[ezrakilty]

Yes, 1–3 are exactly what I have in mind for those parts. I haven't yet totally envisioned how #4, the version dependencies, will actual work. But I think it works to have network-uri-static specify an upper-bound for the version of network-uri that it can be used with.

You allude to another option, where network-uri-static could become "empty" if network-uri version is newer than a certain version. Do you know how to do that? Would it require the C preprocessor option? From the user's point of view, I suppose it would be smoother because they wouldn't have to update their .cabal files to express different package dependencies. If we create a new incompatibility between (certain versions of) these two packages, then I suppose a lot of people will have to update .cabal files.

[snakamura]

I've created a sample project at https://github.com/snakamura/project_version that demonstrates how we can control exposed modules depending on versions of dependencies. I think we can use this strategy to network-uri and network-uri-static.

[ezrakilty]

This is great, thank you.

There is a similar sort of flag which is already present in network-uri to handle the fact that it was split off from network some time ago. This flag imposes a noticeable burden on every single user of network-uri, which is in the hundreds, so I'm a little cautious here.

My ideal would be that users of network-uri and network-uri-static do not have to make any changes to their .cabal files. (Other than updating version numbers as cabal install would direct, which is normal for updating packages.)

Given the approach in this proposal, I'm not sure whether that ideal would be achieved. The role of b could be played by any downstream packages, but it would still require them to specify the old-a flag, depending on whether they want to be up-to-date or not, and they'd have to think about and understand that before upgrading. Is that true? Also I think downstream libraries would need to provide such a mechanism to pass through the flag to their own consumers.

It seems that, for the ideal, what we need is a way for network-uri-2.7 to declare its incompatibility with network-uri-static, or with today's versions of network-uri-static (versions <0.2). We could do that, if we actually require network-uri-static<0.2 from network-uri. I'm imagining a version of network-uri-static 0.2 which is simply empty, so that it would effectively exclude all the definitions that would conflict. That's slightly awkward, in that it would require people that have never needed network-uri-static to install this new, empty, package. But at least it would force the cabal install process to work correctly, giving people a working set of packages. And the new network-uri-static package would be quite low-cost.

I feel a bit limited in not having worked with cabal very much, so I could be missing something important. Please do enlighten me if I'm myopic in that way. I'm very much hoping for a way to place a minimal impact on all the consumer modules.

[snakamura]

I'm not a cabal expert, but as far as I know, cabal tries different flags when it resolves dependencies.

With my sample projects, when you try to install b with a-2, cabal resolves dependencies with the default flag (old-a is False) and b exposes nothing. When you try to install b with a-1, cabal cannot resolve dependencies with old-a being False, so it tries resolving dependencies by changing old-a to True, which succeeds. In this case, b exposes A.

In our case, a is network-uri, b is network-uri-static, c is a library/program using network-uri and network-uri-static. This means network-uri-static exposes nothing when you try to install it with a new network-uri, while it exposes Network.URI.Static when you install it with an old network-uri.

If I understand it correctly, users of network-uri-static doesn't need to update their cabal files other than bumping versions of dependencies.

[ezrakilty]

That sounds very promising; I'll be trying it out tomorrow and hopefully it will work and I will commit it. Thanks for your efforts on this!

[ezrakilty]

OK, this pretty much worked out. See the -static Pull Request here: #6 and the network-uri changes here: haskell/network-uri@5ae30a2

One caveat: If you install the newer network-uri-static (0.1.2.0) before you install the newer network-uri (2.7.0.0) then the former configures itself to expose the module, and then you get an incompatibility on the installation of network-uri. I'm not sure that there's anything to prevent that on the user's end. The only thing I found to get around it was clearing my whole sandbox and reinstalling in the other order.

[snakamura]

@ezrakilty Thank you. I'm going to merge #6. Regarding haskell/network-uri@25f5022, it doesn't seem to contain the recent changes merged in #3. As I've already released a version including these changes, can you include them to network-uri?

[ezrakilty]

You're right I hadn't pulled those changes over. I think this is all up to date now: https://github.com/haskell/network-uri/blob/static/Network/URI/Static.hs

[snakamura]

Thank you. I looks good to me.

[ezrakilty]

I've integrated the Tutorial from network-uri-static's README.md into network-uri's. Would you like me to copy the copyright statement over as well? The network-uri copyright (in LICENSE) currently just reads like this:

Copyright (c) 2002-2010, The University Court of the University of Glasgow.
Copyright (c) 2007-2010, Johan Tibell

The license is BSD 3-clause. I presume you are OK with that as well.

[snakamura]

Thank you for confirming this, but I'm fine with not copying any copyright statement from this library.

[qrilka]

It looks like network-uri-2.6.2.0 already includes Lift instances but the repo expects them to be introduced in 2.7 - shouldn't that be fixed?

[ezrakilty]

We're working on that over here: #9 although I'm struggling with Git a little bit.

[emberdart]

Looks like this happened - will this package be deprecated?