Vcpkg: Please rename range-v3 package

[ericniebler]

It is not range-v3. It is "Range-v3-VS2015", which is a a separate fork with different source code. It points to https://github.com/Microsoft/Range-V3-VS2015. I would expect a "range-v3" project to pull from https://github.com/ericniebler/range-v3. cc @CaseyCarter

[CaseyCarter]

I've changed the "range-v3" vcpkg so that it assembles the library in two phases:

1. Pull sources from ericniebler/range-v3@6eb5c831ffe12cd5cb96390dbe917ca1b248772d
2. Apply MSVC workaround patch from https://github.com/Microsoft/Range-V3-VS2015/compare/6eb5c831ffe12cd5cb96390dbe917ca1b248772d...2cb66781c8ac72a55fff1436e8fc8170a2ce8509

Which (hopefully) clarifies that the library is composed of two parts, one of which is a greatly out-of-date version of range-v3. Does that address your concerns?

[ericniebler]

Does that address your concerns?

No. When people take a dependence on something called "range-v3", they should get range-v3, not some old, out of date range-v3 with patches. Look at the confusion this is causing:

https://conan.io/source/range-v3/0.0.0-1/lasote/vcpkg

The Conan "range-v3" package is pointing to the vcpkg package, so everybody who takes a dependence on "range-v3" is getting some horribly out-of-date version with Microsoft-specific patches. I don't want that.

Please change the name of vcpkg's range-v3 package to "Range-v3-VS2015" to avoid this confusion.

[KindDragon]

But range-v3 master can't be compiled in VS2015 and vcpkg support only VS2015. It maybe is better to add versions to range-v3?

[ericniebler]

Calling it range-v3 is causing confusion. I have filed a separate issue (conan-io/conan#575) about the problem in Conan -- which is a cross-platform package manager -- but the fact is this wouldn't have happened if the package had just been called Range-v3-VS2015 to begin with. Adding versions to range-v3 doesn't sound like it will resolve the confusion.

[ras0219-msft]

I'd like to interject with a few clarifications.

First, in the same manner as the multitude of other systems package managers such as apt-get, pacman, and homebrew, we intend the package named after a library to follow the original sources as closely as possible given the system's constraints. We do not accept additional functionality as a patch; these patches should be workarounds for bugs in the compiler or to fix incompatibilities with other libraries in our ecosystem. Our goal with any patches is that they are suitable to be upstreamed and removed from the Vcpkg ports tree; if upstream solves the compatibility problem in a different way, we will make breaking changes to follow what upstream's solution is (given the compiler and library version constraints mentioned previously). It is explicitly stated to all vcpkg users that we patch upstream sources to improve ecosystem compatibility (exactly the same as the industry-wide practice for other package managers), and this is noted during the build of every package:

PS D:\src\vcpkg> vcpkg build range-v3
...
-- Applying patch D:/src/vcpkg/downloads/range-v3-fork_base_to_2cb66781c8ac72a55fff1436e8fc8170a2ce8509.diff
-- Applying patch D:/src/vcpkg/downloads/range-v3-fork_base_to_2cb66781c8ac72a55fff1436e8fc8170a2ce8509.diff done
...

In this concrete case, the only way to use range-v3 with MSVC 19 (that I'm aware of) is with the patches provided by @CaseyCarter; if there is an alternative path that requires less modification (ideally none!), we will move to that as quickly as possible.

The conan "range-v3/vcpkg" package is part of an experiment they are running to repackage all the ports in our tree (see https://github.com/conan-io/conan-io.github.io/blob/develop/_posts/2016-10-17-Using-Vcpkg-ports-as-Conan-packages.markdown). All packages produced this way have a "/vcpkg" tacked on to distinguish them from the pure upstream sources and indicate that the patches present in the Vcpkg system have been applied.

[ericniebler]

Thanks for the clarification. I see your reasons.

we intend the package named after a library to follow the original sources as closely as possible given the system's constraints

Sure. But unfortunately, Range-v3-VS2015 doesn't track upstream very closely. It's more than a year out of date. There have been important fixes and improvements since then. I would be far more comfortable with this setup if the vcpkg used more current sources for range-v3.

if there is an alternative path that requires less modification (ideally none!), we will move to that as quickly as possible

Understood. Unfortunately, the patch to make range-v3 work with vs2015 is too invasive to be accepted upstream at this time.

All packages produced this way have a "/vcpkg" tacked on to distinguish them from the pure upstream sources and indicate that the patches present in the Vcpkg system have been applied.

I see. I will work with the Conan guys to produce a proper range-v3 package that tracks upstream releases directly.

Thanks for working with me on this issue. Closing.

[ras0219-msft]

Thank you for expressing your concerns and making an awesome library! I'll look forward to when we can use it completely unmodified.

[ericniebler]

Now that vcpkg works on Linux and MacOS, it is more important than ever that the "range-v3" package pull from GitHub.com/ericniebler/range-v3. Users of platforms other than vc2015 have no reason to expect that a package called "range-v3" would pull from any other source. The arguments given above use the fact that vcpkg was only for vc2015 users to justify closing the bug. Please reconsider.

Attn: @CaseyCarter

[CaseyCarter]

@ras0219-msft and I had a recent hallway discussion about range-v3 being broken in cross-plat vcpkg. There's a plan to have range-v3 actually be range-v3 on non-Windows (crazy, I know) and continue to install the fork on Windows for the time being.

Apologies for not thinking about this sooner and getting things straightened out before the cross-platform announcement.

[ericniebler]

Apologies for not thinking about this sooner and getting things straightened out before the cross-platform announcement.

Should read: "apologies for not fixing the problem when you first raised it over a year ago." :-P

Regardless, thank you.

[MikeGitb]

seems to be fixed in https://github.com/Microsoft/vcpkg/commit/4d28651f9ea0c6681d73b133386a42e1924d4b33 right?

[CaseyCarter]

seems to be fixed in 4d28651 right?

Not exactly: there's no reason that users of Clang on Windows should have to suffer the slings and arrows of Range-V3-VS2015 simply because MSVC can't compile upstream range-v3. (I suspect the set of users compiling range-v3 with Clang on Windows using the MSFT STL is very small: many things didn't work until https://github.com/ericniebler/range-v3/pull/833 was merged three weeks ago, and range-v3 has never had a single bug report for the problems that PR works around.)

At this point I don't think we can reconcile the competing "MSVC needs to compile everything vcpkg installs" and "range-v3 should always install upstream range-v3" viewpoints otherwise than to fix MSVC so it can compile range-v3. When that day comes, I will close this issue, delete Range-V3-VS2015, and rejoice.

[jeanga]

Time to rejoice?

[CaseyCarter]

Thank you for the reminder! This issue is fixed by #4669.