Deciding whether to create a new package or take over an abandoned one

#1

Hello, community.

I would like to create my first package which would solve the problem of parsing Kindle “MyClippings.txt” file. Searching Hackage, I found one:

I should note “Last success reported on 2015-08-27”, and when I try to install the package with cabal, I get errors. So, my question is:

In this scenario, is it better to create a new package, or take over the existing one ?

I would appreciate the wisdom of the community.

P.D.: If I create a new one, I think my choice would be Hutton’s parser combinators library.

1 Like
#2

My view is to ask the author politely if you can take over maintainership:

  • if they refuse, create a new package.
  • if they accept or are not responsive, take over the package.

Motivation: Hackage real estate is a finite resource.

4 Likes
#3

Thank you. That was exactly my concern. That’s way I asked here where more experienced users like yourself could provide their opinion.

If they are not responsive, how do I take over the package ?

#4

I’d say you should first use up all available “real estate” and only start taking over unmaintained packages if no good names are left over. Even if Hackage is a finite resource, you shouldn’t start paying the price for that before it has ran out.

See Taking over a package.

2 Likes
#5

Thank you @jaror and @f-a. I have contacted the author via mail and I get “Delivery Status Notification (failure)” :slight_smile:

Isn’t the best for Hackage to at least provide a tag to identify those that don’t compile ?

I guess I could take over the package since I do not get any response; I will contact Hackage.

1 Like
#6

IMO it’s always better to take over an existing abandoned package than create a new one. It makes choice of users easier and saves namespaces.

9 Likes
#7

I would suggest downloading the .tar.gz off of Hackage, and adding a stack.yaml and seeing if an older Stackage lts will get it to compile. Then you can kick the tires a little to see if you would want to take it over.

1 Like
#8

Thank you. I have downloaded .tar.gz and this is the error I get with cabal build

1.329s  ~ % cabal build
Resolving dependencies...
cabal: Could not resolve dependencies:
[__0] trying: clippings-0.2.0 (user goal)
[__1] trying: functor-infix-0.0.5 (dependency of clippings)
[__2] next goal: template-haskell (dependency of functor-infix)
[__2] rejecting: template-haskell-2.18.0.0/installed-2.18.0.0 (conflict:
functor-infix => template-haskell>=2.8 && <2.17)
[__2] skipping: template-haskell-2.20.0.0, template-haskell-2.19.0.0,
template-haskell-2.18.0.0, template-haskell-2.17.0.0 (has the same
characteristics that caused the previous version to fail: excluded by
constraint '>=2.8 && <2.17' from 'functor-infix')
[__2] rejecting: template-haskell-2.16.0.0, template-haskell-2.15.0.0,
template-haskell-2.14.0.0, template-haskell-2.13.0.0,
template-haskell-2.12.0.0, template-haskell-2.11.1.0,
template-haskell-2.11.0.0, template-haskell-2.10.0.0,
template-haskell-2.9.0.0, template-haskell-2.8.0.0, template-haskell-2.7.0.0,
template-haskell-2.6.0.0, template-haskell-2.5.0.0, template-haskell-2.4.0.1,
template-haskell-2.4.0.0, template-haskell-2.3.0.1, template-haskell-2.3.0.0,
template-haskell-2.2.0.0 (constraint from non-upgradeable package requires
installed instance)
[__2] fail (backjumping, conflict set: functor-infix, template-haskell)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: base, template-haskell, functor-infix,
clippings

Any clues or pointers would be appreciated.

I’ll try that.

#9

The important line is:

[__2] rejecting: template-haskell-2.18.0.0/installed-2.18.0.0 (conflict: 
functor-infix => template-haskell>=2.8 && <2.17)

That means that it requires a template-haskell below 2.17 and template-haskell is a non-reinstallable library so you can only use it with one specific version of GHC. You can look on this GHC wiki page to see that 2.17 corresponds to GHC 9.0, so it may work if you use GHC 8.10.7.

#10

Thank you @jaror.

Doesn’t the error message say that template-haskellversion should be >= 2.8 && ; 2.17 ? And I see it’s impossible to satisfy that constraint.

#11

I used Haskell Playground (GHC 8.10.7) with this code, and I get:

module Main where

import Data.Functor.Infix

main = do
  putStrLn "Hello, World!"

Could not find module ‘Data.Functor.Infix’
    Perhaps you meant
      Data.Functor.Alt (from semigroupoids-5.3.7)
      Data.Functor.Apply (from semigroupoids-5.3.7)
      Data.Functor.Bind (from semigroupoids-5.3.7)
    Use -v (or `:set -v` in ghci) to see a list of the files searched for.
#12

Yes it also has a lowe bound of 2.8, but the upper bound is more important as that’s probably what you want to get closest to. And no, it is not impossible to satisfy. For example 2.17 which comes with GHC 8.10 does satisfy that constraint (note that 2.8 means 2.08 and not 2.80).

The Haskell playground has a limited set of packages available. functor-infix is not in that set.

1 Like
#13

That looks pretty typical of cabal, Hackage say’s the last successful build was with ghc-7.8.3, that would be the Stackage lts-0.7, that’s pretty old…

The Stackage lts-6.35 might be a better bet, since it’s the last of the ghc-7.x series, and only 6 years out of date.

Think of it as going on an adventure in Hackage necromancy!

#14

I’ve looked at the source code. The package functor-infix is only required for the function <$$> in Text.Kindle.Clippings.Reader.

<$$> is simply a convenience function equal to fmap . fmap. Because it’s such a small amount of code, I suggest removing the dependency on functor-infix and copying the definition of <$$> from functor-infix directly into Text/Kindle/Clippings/Reader.hs. That should make it possible to use a recent Stackage version.

1 Like
#15

I’m actually not sure.

There is one counter argument to it: I often choose the packages I frequently depend on by the author/maintainer, less so by features and API. Do I trust them, do I know they’re experts and not just dumping an experiment on hackage?

There’s maintainers I have personally blacklisted, because I don’t trust them to maintain e.g. secure packages.

When a package takeover happens, it’s often hard for users like me to know and reevaluate whether I want to trust the new maintainers.

I guess that could somehow be assisted with tooling, but often times the maintainer field in cabal files isn’t very reliable. Or I simply have never heard of the new maintainer and their hackage footprint is zero.

As such, fluid maintainership can disrupt the trust relationship between users and package.

I’m not advocating to stop package takeovers, but e.g. hackage namespaces could solve this problem.

Edit: that’s also why I’m quite sceptical of things like Haskell GitHub Trust. Do you want lots of people have commit access to crypto packages?

1 Like
#16

that’s also why I’m quite sceptical of things like Haskell GitHub Trust. Do you want lots of people have commit access to crypto packages?

Haskell Github Trust is not for popular important packages lovingly maintained by cryptography experts. It’s for low-interest packages which a small number of people find useful sometimes.

The clippings package

is a perfect candidate for Haskell Github Trust: a parser for Kindle files, with 9 downloads in the last month, last updated in 2015.

4 Likes
#17

Don’t get me wrong, I welcome comaintenance projects. But it does make it harder for people to assess the quality of maintenance.

I raised some of my concerns here: Introduce Haskell Party proposal by bergmark · Pull Request #12 · haskellfoundation/stability · GitHub

I’d personally only use such comaintenance if I could define a custom patch policy (e.g. no feature patches in my absence, or no major refactorings). But at that point, I’m probably better off managing my contributors directly.

I don’t have a definite answer on the topic as a whole, but wanted to share my doubts.

1 Like
#18

Thank you everyone for your valuable inputs !

That’s very funny ! I am enjoying the ride so far.

Thank you so much. That did it. Compilation is successful now.

#19 
parseDate :: String -> LocalTime
parseDate raw = fromMaybe defaultLocalTime . join . find isJust . map (fst <$$> flip strptime raw) $
  [ "%A, %d %B %y %X"  -- Thursday, 01 January 70 12:00:00 AM
  , "%A, %B %d, %Y %r" -- Thursday, January 01, 1970 12:00:00 AM
  ]

defaultLocalTime :: LocalTime
Just (defaultLocalTime, _) = strptime "" ""

I noticed that section of code, raises the following warning:

src/Text/Kindle/Clippings/Reader.hs:87:1: warning: [-Wincomplete-uni-patterns]
    Pattern match(es) are non-exhaustive
    In a pattern binding:
        Patterns of type ‘Maybe (LocalTime, String)’ not matched: Nothing
   |
87 | Just (defaultLocalTime, _) = strptime "" ""

Is there a more up-to-date way to handle the parsing of that date ?

#20

I asked haskell-cafe about takeover process, and they said publicly annoncíng my intention on discourse is fine, since I can’t suscribe to haskell-cafe mailing list.