fosskers / versions Goto Github PK

I think it might be sufficient to bump the bound on base.

ie this removes the 0.

λ> DV.prettySemVer <$> DV.semver "2.2.1-b05"
Right "2.2.1-b5"

My use case is I was to convert a bunch of textual versions to Version, find the maximum, then get back the same textual representation for further use.

Not sure if this is a bug as such or a design decision.

Hi!

With versions version 5.0.0, I get the following behavior:

*Data.Versions> let showVer = putStrLn . either errorBundlePretty (Data.Text.unpack . prettySemVer)  . semver
*Data.Versions> showVer "1.2.2-00a"
Semantic Version:1:8:
  |
1 | 1.2.2-00a
  |        ^
unexpected '0'
expecting '+', '.', or end of input

*Data.Versions> showVer "1.2.2-0a"
1.2.2-0a
*Data.Versions>

-- | Convert a `Version` back to its textual representation.
prettyVer :: Version -> Text
prettyVer (Version ep cs pr me) = ep' <> mconcat (ver <> me' <> pr')
  where
    ver = intersperse "." . chunksAsT $ NEL.toList cs
    me' = maybe [] (\m -> ["+",m]) me
    pr' = foldable [] ("-" :) $ intersperse "." (chunksAsT pr)
    ep' = maybe "" (\e -> showt e <> ":") ep

Prelude Data.Versions GHCup.Utils.Prelude GHCup> Right v <- pure $ version "9.2.1.b-debug+lol"
Prelude Data.Versions GHCup.Utils.Prelude GHCup> prettyVer v
"9.2.1.b+lol-debug"

meta and rel are swapped.

    SemVer - Arbitrary:                          FAIL
      *** Failed! Falsifiable (after 4 tests):
      SemVer {_svMajor = 4, _svMinor = 2, _svPatch = 3, _svPreRel = [[Digits 2,Digits 4,Str "h"],[Digits 0,Digits 2],[Str "gaw"
,Str "tz"]], _svMeta = [[Digits 0],[Str "hnj"],[]]}
      Use --quickcheck-replay=501870 to reproduce.

versions was disabled for bounds reasons but now this popped up, please send a PR to re-enable it if it gets fixed or let us know if we should just ignore the test failure.

On certain Ubuntu configurations, the output of clang --version will be something like this:

Ubuntu clang version 12.0.0-3ubuntu1~20.04.5
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

I'm interested in being able to parse the 12.0.0-3ubuntu1~20.04.5 bit. Currently, all of the parsers that the versions library offers (ranging from versioning to mess) will choke on this version due to the fact that it contains a tilde:

λ> case mess "12.0.0-3ubuntu1~20.04.5" of Left e -> error $ errorBundlePretty e
*** Exception: Mess:1:16:
  |
1 | 12.0.0-3ubuntu1~20.04.5
  |                ^
unexpected '~'
expecting '+', '-', '.', ':', '_', digit, end of input, letter, or white space

I doubt that this is a valid SemVer, but is there a way to make mess accept this?

Looks like that your package(s) are following the Semantic Versioning -scheme. That's great, but it would be even better if it followed the Package Versioning Policy (PVP). In a nutshell, PVP has the same principles as the SemVer, but it talks specifically about Haskell, and has different meaning for the version digits: major1.major2.minor.patch. Even that bumping the versions according do SemVer doesn't violate PVP, it is unnecessarily over-conservative, and thus might be inconvenient for the downstream users. For example Stackage LTS allow only the minor (the third digit) updates inside major LTS version.

From the homepage of Hackage

Guidelines for Hackage Packages:

• All packages should follow the Package Versioning Policy (PVP).

cc @bergmark @hvr

Hello. When parsing a string with trailing whitespace, the trailing whitespace is ignored and the parse succeeds:

> versioning "1   \t  \n "

Right (General (Version {_vEpoch = Nothing, _vChunks = [[Digits 1]], _vRel = []}))

If there is leading whitespace we get an error:

> versioning " 1"
Left (ParseErrorBundle {bundleErrors = TrivialError 1 (Just (Tokens ('1' :| ""))) (fromList [Label ('w' :| "hite space"),EndOfInput]) :| [], bundlePosState = PosState {pstateInput = " 1", pstateOffset = 0, pstateSourcePos = SourcePos {sourceName = "versioning", sourceLine = Pos 1, sourceColumn = Pos 1}, pstateTabWidth = Pos 8, pstateLinePrefix = ""}})

I personally think that trailing whitespace should also be an error (I've never seen in the wild a "version" that contains whitespace characters. And this packages rightfully rejects versions with whitespace in the middle of the string, so it should do the same also for whitespace at the end. Also, trailing whitespace breaks the round-trip parse/print property)

Thank you

https://semver.org/ defines two incompatible versions of semantic versioning. Does this package implement 1.0.0 or 2.0.0? Can we get this in the documentation?

I noticed PVP is not in Versioning. I guess the main problem is that PVP doesn't safely degrade to SemVer and SemVer doesn't safely degrade to PVP. Is that a semantics of Versioning (in respect to the Ord instance) that is expected?

I have issue with comparing short and full notations of same versions. E.g:

> import Data.Versions
> Right v1 = parseV "1.2.0"
> Right v2 = parseV "1.2"
> compare v1 v2
GT

I think they should be equal. Or it's expected behavior?

Here are two examples of semantic versions that are valid (they are examples taken directly from the spec at https://semver.org/), but fail to parse with semver:

-- From https://semver.org/#spec-item-9
> semver "1.0.0-x-y-z.-"
Left (ParseErrorBundle {bundleErrors = TrivialError 7 (Just (Tokens ('-' :| ""))) (fromList [Tokens ('+' :| ""),Tokens ('.' :| ""),Tokens ('0' :| ""),Label ('d' :| "igit"),Label ('l' :| "etter"),EndOfInput]) :| [], bundlePosState = PosState {pstateInput = "1.0.0-x-y-z.-", pstateOffset = 0, pstateSourcePos = SourcePos {sourceName = "Semantic Version", sourceLine = Pos 1, sourceColumn = Pos 1}, pstateTabWidth = Pos 8, pstateLinePrefix = ""}})

-- From https://semver.org/#spec-item-10
> semver "1.0.0-alpha+001"
Left (ParseErrorBundle {bundleErrors = TrivialError 13 (Just (Tokens ('0' :| ""))) (fromList [Tokens ('.' :| ""),EndOfInput]) :| [], bundlePosState = PosState {pstateInput = "1.0.0-alpha+001", pstateOffset = 0, pstateSourcePos = SourcePos {sourceName = "Semantic Version", sourceLine = Pos 1, sourceColumn = Pos 1}, pstateTabWidth = Pos 8, pstateLinePrefix = ""}})

> semver "1.0.0+21AF26D3--117B344092BD"
Left (ParseErrorBundle {bundleErrors = TrivialError 14 (Just (Tokens ('-' :| ""))) (fromList [Tokens ('.' :| ""),Tokens ('0' :| ""),Label ('d' :| "igit"),Label ('l' :| "etter"),EndOfInput]) :| [], bundlePosState = PosState {pstateInput = "1.0.0+21AF26D3--117B344092BD", pstateOffset = 0, pstateSourcePos = SourcePos {sourceName = "Semantic Version", sourceLine = Pos 1, sourceColumn = Pos 1}, pstateTabWidth = Pos 8, pstateLinePrefix = ""}})

It seems like pre-release version tags and build metadata are not being correctly parsed. In particular:

• Numeric identifiers in build metadata is allowed to have leading zeroes.
• Identifiers in general are allowed to have hyphen.

Hello. It appears that when calling versioning "" we get a valid version:

(General (Version {_vEpoch = Nothing, _vChunks = [[]], _vRel = []}))

Is this intended? I personally think this should be an error, but either way maybe it is worth documenting

Thank you

It is very useful to be able to call the version function within a Template Haskell splice so that one can throw a compile-time error if the version number is malformed:

ver :: Text -> Q Exp
ver nm =
  case Versions.version nm of
    Left err -> fail (errorBundlePretty err)
    Right v  -> lift v

Currently, this function doesn't work out of the box, as the Version data type (which version returns) does not define a Lift instance. As a result, we have to define our own orphan Lift instances to make this work.

Would you be OK with defining the Lift instances directly in the versions library? Something like this would suffice:

deriving instance Lift Chunk
deriving instance Lift Chunks
deriving instance Lift Release
deriving instance Lift Version

Any interest in adding this package to Stackage?

https://github.com/fpco/stackage#add-your-package

versions 4.0.2 builds with GHC 9.0.1

In my opinion, there are a few typeclasses for which most (serializable, non-abstract) datatypes should have instances. The bare minimum in my view includes Generic and Data, but Ord (for use with containers), Hashable (for use with unordered-containers), and NFData (allows deepseq) are also often useful. Defining these instances in this library would prevent downstream users from having to add orphan instances (which can be very problematic if the downstream user is itself a library) or newtype wrappers. This problem is exacerbated if the datatype in question is one that is likely to be included as a part of a larger datatype, which seems likely for the types in this library. Since this library doesn't define very many types, the slightly increased compile times shouldn't be a problem.