Policy for taking over a package on Hackage

Ivan Lazar Miljenovic

25 May 2011 25 May '11

8:01 a.m.

With my wl-pprint-text package, Jason Dagit suggested to me on #haskell that it would make sense to make such a pretty-printer be class-based so that the same API could be used for String, ByteString, Text, etc. I was thinking of doing so, and in such a case it would probably make the most amount of sense to actually then migrate the package back to the wl-pprint package instead of defining yet another package (and corresponding namespace), especially as I recalled from when I first started hacking on wl-pprint-text at the beginning of the year that the last (and only) upload had been in 2007 by Stefan O'Rear. As such, I was going to email Stefan and asked if he minded if I took over maintaining wl-pprint. However, when I went to the package page to get his email address, I saw that Otakar Smrz had released a new version about a month ago, and that the only change in the package that I could find was that OverlappingInstances was added to the .cabal file (which I thought wouldn't make a difference anyway). Now, for all I know, Otakar had already asked Stefan for permission to take over the package (I've CC'd both of them just in case). But even if he didn't, we don't officially have any policies set in place - especially ones that are enforced by requiring registering a package and specifying a maintainer - to indicate that such a thing shouldn't be done. Furthermore, if packages aren't announced then there's no way for people to know that there _is_ a new maintainer. This situation also arose last year [1], and was resolved by someone volunteering to take over a package. However, no formal policy was set in place (despite one being proposed). As such, I'd like to propose the following policy based upon the one Ben Millwood proposed last time on how to take over maintainership of a package that hasn't been updated for a while: 1. Email the current listed maintainer and wait a specified period of time (e.g. 2 weeks). 2. Email haskell-cafe, explicitly CC'ing maintainers of reverse dependencies (at least those that are themselves still active) and request permission to take over. This way, people who know the maintainer might point out that they are indeed still around, etc. 3. If no-one objects within another two weeks, announce that you have taken over maintainership with a new email (in case people are ignoring the previous thread). 4. Upload a point release of the previous package (assuming it follows the PVP) with yourself as the new maintainer (just to get it out there). Alternatively, if you already have a new version ready to go then upload that. Of course, having a policy like this is useless if there is no way to enforce it. Is it possible at the very least to have Hackage note when a new version of a package is uploaded with a new maintainer and require it to be approved by someone before it iis officially available? I think this would be the bare minimum (as opposed to requiring explicit logins on a per-package basis or some kind of signing) required for this kind of scheme to be effective. [1]: http://www.haskell.org/pipermail/haskell-cafe/2010-August/081353.html and http://www.haskell.org/pipermail/haskell-cafe/2010-August/082319.html -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

Show replies by date

Stephen Tetley

25 May 25 May

8:17 a.m.

Hi Ivan Forks are good, no? The Parsec experience has suggested to me at least, that new author's "capping" another author's work by bumping up to a major version, causes a significant difficulties even when the original author has gone. As for wl-pprint, it was a very tidy library in its original implementation - it's a pity it now has name clashes with Applicative. My feeling is that a new library in a new namespace with some attention to new combinator names would be better.

Ivan Lazar Miljenovic

8:35 a.m.

On 25 May 2011 22:17, Stephen Tetley wrote:

...

Hi Ivan

Forks are good, no?

The Parsec experience has suggested to me at least, that new author's "capping" another author's work by bumping up to a major version, causes a significant difficulties even when the original author has gone.

As for wl-pprint, it was a very tidy library in its original implementation - it's a pity it now has name clashes with Applicative. My feeling is that a new library in a new namespace with some attention to new combinator names would be better.

Such as? I'm _hopeless_ at making up names... ;-) Having a new package would require a new name and new module namespace, let alone thinking up new names for combinators... Also, by clashes with Applicative, are you referring to empty and <$> ? I'm not sure if a better name than "empty" can be found; as for <$>, maybe using pretty's notation of $$ and $+$ rather than <$> and <$$> ? -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

Simon Meier

8:45 a.m.

2011/5/25 Ivan Lazar Miljenovic :

...

On 25 May 2011 22:17, Stephen Tetley wrote:

...
Hi Ivan

Forks are good, no?

The Parsec experience has suggested to me at least, that new author's "capping" another author's work by bumping up to a major version, causes a significant difficulties even when the original author has gone.

As for wl-pprint, it was a very tidy library in its original implementation - it's a pity it now has name clashes with Applicative. My feeling is that a new library in a new namespace with some attention to new combinator names would be better.

Such as? I'm _hopeless_ at making up names... ;-)

Having a new package would require a new name and new module namespace, let alone thinking up new names for combinators...

Also, by clashes with Applicative, are you referring to empty and <$> ? I'm not sure if a better name than "empty" can be found; as for <$>, maybe using pretty's notation of $$ and $+$ rather than <$> and <$$> ?

What about 'emptyDoc'? Moreover, if you are changing the names of combinators, then moving them away from Applicative and Arrow would be a good idea; i.e., don't use <+>, as it already used by ArrowPlus. Moreover, if you can make a Monoid instance such that `mappend` equals <>, you would also make the library compatible to a future introduction of (<>) = mappend. best regards, Simon

KQ

12:07 p.m.

On Wed, 25 May 2011 05:17:46 -0700, Stephen Tetley wrote:

...

Hi Ivan

Forks are good, no?

The Parsec experience has suggested to me at least, that new author's "capping" another author's work by bumping up to a major version, causes a significant difficulties even when the original author has gone.

As for wl-pprint, it was a very tidy library in its original implementation - it's a pity it now has name clashes with Applicative. My feeling is that a new library in a new namespace with some attention to new combinator names would be better.

At the risk of returning to a recurring theme that often comes up but never gets resolved satisfactorily, I'd like to make a cabal proposal: Add to the .cabal file the following optional field: Related-package: ACTION NAME VERSION Information - The first word is the ACTION and is one of: "Replaces", "Redesigns", "Extends", or "Alternative". - The second word is the NAME of the related package. - The third word is the VERSION of the related package. - Any additional text is information describing how the packages relate in descriptive terms and could be a multi-line paragraph like the existing Description: field. There may be multiple "Related-package" entries specifying different packages and actions. Conceptually, the ACTION indicates: - Replaces: This package is intended as a newer replacement to use instead of the older package. It intends to provide all the functionality of the existing package, although perhaps with API or dependency modifications and will probably evolve to provide additional functionality as well (this is probably what Ivan's new package would specify). - Redesigns: This package is intended as a replacement for the older package. It intends to provide similar functionality, but using a new approach and the API (and probably dependencies) is expected to have significant changes. An example of this would be Parsec2 and Parsec3. - Alternative: This package is a horizontal replacement for the other package providing the same type of functionality. The API or dependencies may be a bit different (e.g. mtl and transformers would be Alternatives of each other) but the overall intent of the package is the same. The Information should describe the difference between the two. - Extends: This package uses the previous package and extends it with complementary functionality. For example, attoparsec-binary extends attoparsec. I would suggest the ACTION be limited to known terms such as the above, whereas the Information is free-form for more clarification. The VERSION is important to know where the relationship was established, especially for a Replaces or Alternative type of package where the reference package continues to evolve as well. The HackageDB could the provide this information in the description page of a package, and it could even automatically cross-reference and supplement the referred package descriptions, so that if you are looking at the Parsec2 page it will also show a section "This package has a Redesign: parsec3. The redesign states: ...[Information]......". This type of information can help people know what the alternatives are for various packages and a general understanding of the reason for the proliferation of packages (without having to search haskell-cafe and stack-overflow archives for some discussion that provided the justification/recommendations). Thoughts? -- -KQ

Antoine Latter

1:37 p.m.

On May 25, 2011 11:08 AM, "KQ" wrote:

...

On Wed, 25 May 2011 05:17:46 -0700, Stephen Tetley <

stephen.tetley@gmail.com> wrote:

...

...
Hi Ivan

Forks are good, no?

The Parsec experience has suggested to me at least, that new author's "capping" another author's work by bumping up to a major version, causes a significant difficulties even when the original author has gone.

As for wl-pprint, it was a very tidy library in its original implementation - it's a pity it now has name clashes with Applicative. My feeling is that a new library in a new namespace with some attention to new combinator names would be better.

At the risk of returning to a recurring theme that often comes up but

never gets resolved satisfactorily, I'd like to make a cabal proposal:

...

Add to the .cabal file the following optional field:

Related-package: ACTION NAME VERSION Information

- The first word is the ACTION and is one of: "Replaces", "Redesigns",

"Extends", or "Alternative".

...

- The second word is the NAME of the related package.

- The third word is the VERSION of the related package.

- Any additional text is information describing how the packages relate

in descriptive terms and could be a multi-line paragraph like the existing Description: field.

...

There may be multiple "Related-package" entries specifying different

packages and actions.

...

Conceptually, the ACTION indicates:

- Replaces: This package is intended as a newer replacement to use

instead of the older package. It intends to provide all the functionality of the existing package, although perhaps with API or dependency modifications and will probably evolve to provide additional functionality as well (this is probably what Ivan's new package would specify).

...

- Redesigns: This package is intended as a replacement for the older

package. It intends to provide similar functionality, but using a new approach and the API (and probably dependencies) is expected to have significant changes. An example of this would be Parsec2 and Parsec3.

...

- Alternative: This package is a horizontal replacement for the other

package providing the same type of functionality. The API or dependencies may be a bit different (e.g. mtl and transformers would be Alternatives of each other) but the overall intent of the package is the same. The Information should describe the difference between the two.

...

- Extends: This package uses the previous package and extends it with

complementary functionality. For example, attoparsec-binary extends attoparsec.

...

I would suggest the ACTION be limited to known terms such as the above,

whereas the Information is free-form for more clarification. The VERSION is important to know where the relationship was established, especially for a Replaces or Alternative type of package where the reference package continues to evolve as well.

...

The HackageDB could the provide this information in the description page

of a package, and it could even automatically cross-reference and supplement the referred package descriptions, so that if you are looking at the Parsec2 page it will also show a section "This package has a Redesign: parsec3. The redesign states: ...[Information]......". This type of information can help people know what the alternatives are for various packages and a general understanding of the reason for the proliferation of packages (without having to search haskell-cafe and stack-overflow archives for some discussion that provided the justification/recommendations).

...

Thoughts?

The only thing I'd add would be the additional actions "ReplacedBy", "ExtendedBy" and "RedesignedBy". Antoine

...

-- -KQ

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

quick＠sparq.org

1:50 p.m.

Quoting Antoine Latter :

...

On May 25, 2011 11:08 AM, "KQ" wrote:

...
The HackageDB could the provide this information in the description page

of a package, and it could even automatically cross-reference and supplement the referred package descriptions, so that if you are looking at the Parsec2 page it will also show a section "This package has a Redesign: parsec3. The redesign states: ...[Information]......". This type of information can help people know what the alternatives are for various packages and a general understanding of the reason for the proliferation of packages (without having to search haskell-cafe and stack-overflow archives for some discussion that provided the justification/recommendations).

...
Thoughts?

The only thing I'd add would be the additional actions "ReplacedBy", "ExtendedBy" and "RedesignedBy".

Antoine

I was actually thinking that this was the part that HackageDB could do automatically on the page that the actionBy applied to. There should be enough information in the DB (somewhat like Roel's reverse dependencies work) and the alternative would be having to re-release a package (that you don't necessarily own) to add the actionBy field. -KQ ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/

Antoine Latter

1:56 p.m.

...

Quoting Antoine Latter :

...
On May 25, 2011 11:08 AM, "KQ" wrote:

...
The HackageDB could the provide this information in the description

...

...
of a package, and it could even automatically cross-reference and supplement the referred package descriptions, so that if you are looking at the Parsec2 page it will also show a section "This package has a Redesign: parsec3. The redesign states: ...[Information]......". This type of information can help people know what the alternatives are for various packages and a general understanding of the reason for the proliferation of packages (without having to search haskell-cafe and stack-overflow archives for some discussion that provided the justification/recommendations).

...
Thoughts?

The only thing I'd add would be the additional actions "ReplacedBy", "ExtendedBy" and "RedesignedBy".

Antoine

I was actually thinking that this was the part that HackageDB could do automatically on the page that the actionBy applied to. There should be enough information in the DB (somewhat like Roel's reverse dependencies work) and

I wanted the second set because I may want to establish the link even if I'm not the maintainer of the second package. I would imagine that the second set of actions would be otherwise identical, and the link would show up on either package regardless of which set of verbs was used. Antoine On May 25, 2011 12:50 PM, wrote: page the

...

alternative would be having to re-release a package (that you don't necessarily own) to add the actionBy field.

-KQ

------------------------------------------------- This mail sent through IMP: http://horde.org/imp/

wren ng thornton

6:48 p.m.

On 5/25/11 1:56 PM, Antoine Latter wrote:

...

On May 25, 2011 12:50 PM, wrote:

...
Quoting Antoine Latter:

...
The only thing I'd add would be the additional actions "ReplacedBy", "ExtendedBy" and "RedesignedBy".

I was actually thinking that this was the part that HackageDB could do automatically on the page that the actionBy applied to. There should be enough information in the DB (somewhat like Roel's reverse dependencies work) and the alternative would be having to re-release a package (that you don't necessarily own) to add the actionBy field.

I wanted the second set because I may want to establish the link even if I'm not the maintainer of the second package.

I would imagine that the second set of actions would be otherwise identical, and the link would show up on either package regardless of which set of verbs was used.

Exactly. Sometimes the new package designer may be unaware of the prior art, or may be too timid to declare obviating another's work. Also, allowing for both sides to declare the link can help to serve as verification of the relationship. If someone uploads the 'awesome' package which declares itself to replace everything on Hackage, should we just accept it at face value? Moreover, a feature like this new field would be useful for pruning the list of packages shown on the index, but do we want to allow the maintainer of package A to simply fiat that package B shouldn't be shown on the index anymore? We have a nice community, but security and validation are still good things to plan into the design. -- Live well, ~wren

wren ng thornton

6:41 p.m.

On 5/25/11 1:37 PM, Antoine Latter wrote:

...

On May 25, 2011 11:08 AM, "KQ" wrote:

...
At the risk of returning to a recurring theme that often comes up but never gets resolved satisfactorily, I'd like to make a cabal proposal:

Add to the .cabal file the following optional field:

Related-package: ACTION NAME VERSION Information

- The first word is the ACTION and is one of: "Replaces", "Redesigns", "Extends", or "Alternative".

- The second word is the NAME of the related package.

- The third word is the VERSION of the related package.

- Any additional text is information describing how the packages relate in descriptive terms and could be a multi-line paragraph like the existing Description: field. [...]

The only thing I'd add would be the additional actions "ReplacedBy", "ExtendedBy" and "RedesignedBy".

+1. Though this should probably be made into a formal ticket for Cabal (especially of the "please apply this patch" variety). I think lack of implementation has always been a bigger issue than disagreement about this feature. -- Live well, ~wren

Johan Tibell

8:52 a.m.

On Wed, May 25, 2011 at 2:01 PM, Ivan Lazar Miljenovic wrote:

...

With my wl-pprint-text package, Jason Dagit suggested to me on #haskell that it would make sense to make such a pretty-printer be class-based so that the same API could be used for String, ByteString, Text, etc.

I'm a bit skeptical of using type classes to abstract over Unicode string types and byte sequence types. The only API shared by the two kind of types is that of a sequence. Things like dot , spaces, etc. don't make much sense on binary data. You must assume that the ByteString contains text in some encoding to make sense of such concepts. Johan

Ivan Lazar Miljenovic

8:59 a.m.

On 25 May 2011 22:52, Johan Tibell wrote:

...

On Wed, May 25, 2011 at 2:01 PM, Ivan Lazar Miljenovic wrote:

...
With my wl-pprint-text package, Jason Dagit suggested to me on #haskell that it would make sense to make such a pretty-printer be class-based so that the same API could be used for String, ByteString, Text, etc.

I'm a bit skeptical of using type classes to abstract over Unicode string types and byte sequence types. The only API shared by the two kind of types is that of a sequence. Things like dot , spaces, etc. don't make much sense on binary data. You must assume that the ByteString contains text in some encoding to make sense of such concepts.

Well, using the Char8 version. I was thinking of a class looking something like: class (IsString s, Monoid (Builder s)) => Prettyable s where type Builder s toBuilder :: s -> Builder s fromBuilder :: Builder s -> s And then Doc now takes in a type parameter, which needs to be an instance of Prettyable. The IsString constraint is so that combinators like "int" and "double" can be defined via show (rather than have them being class-level methods), toBuilder is used to convert an actual s value to (Doc s) and fromBuilder is used for the final rendering at the end. The only other thing I can think of that _may_ need to be done on a class level is the allowable size lengths of values (Int64 for lazy ByteString and Text, and possibly just Int for convenience with String). Though if displayIO is going to be kept some kind of "s -> IO ()" method will also be needed, though arguably displayIO isn't that necessary. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

Bryan O'Sullivan

1:03 p.m.

On Wed, May 25, 2011 at 5:59 AM, Ivan Lazar Miljenovic < ivan.miljenovic@gmail.com> wrote:

...

Well, using the Char8 version.

Just because you *could* do that, it doesn't mean that you *should*. It's a bad idea to use bytestrings for manipulating text, yet the only plausible reason to have wl-pprint handle bytestrings is so that they can be used as text.

wren ng thornton

6:49 p.m.

On 5/25/11 1:03 PM, Bryan O'Sullivan wrote:

...

On Wed, May 25, 2011 at 5:59 AM, Ivan Lazar Miljenovic< ivan.miljenovic@gmail.com> wrote:

...
Well, using the Char8 version.

Just because you *could* do that, it doesn't mean that you *should*. It's a bad idea to use bytestrings for manipulating text, yet the only plausible reason to have wl-pprint handle bytestrings is so that they can be used as text.

It's worth highlighting that even with the Char8 version of ByteStrings you still run into encoding issues. Remember the days before Unicode came about? True, 8-bit encodings are often ASCII-compatible and therefore the representation of digits and whitespace are consistent regardless of (ASCII-compatible) encoding, but that's still just begging for issues. What are the semantics of the byte 0xA0 with respect to pretty-printing issues like linewraps? Are they consistent among all extant 8-bit encodings? What about bytes in 0x80..0x9F? What about 0x7F for that matter? I won't say that ByteStrings should never be used for text (there are plenty of programs whose use of text involves only whitespace splitting and moving around the resultant opaque blobs of memory). But at a bare minimum, the use of ByteStrings for encoding text needs to be done via newtype wrapper(s) which keep track of the encoding. Especially for typeclass instances. -- Live well, ~wren

Ivan Lazar Miljenovic

7:02 p.m.

On 26 May 2011 08:49, wren ng thornton wrote:

...

On 5/25/11 1:03 PM, Bryan O'Sullivan wrote:

...
On Wed, May 25, 2011 at 5:59 AM, Ivan Lazar Miljenovic< ivan.miljenovic@gmail.com> wrote:

...
Well, using the Char8 version.

Just because you *could* do that, it doesn't mean that you *should*. It's a bad idea to use bytestrings for manipulating text, yet the only plausible reason to have wl-pprint handle bytestrings is so that they can be used as text.

It's worth highlighting that even with the Char8 version of ByteStrings you still run into encoding issues. Remember the days before Unicode came about? True, 8-bit encodings are often ASCII-compatible and therefore the representation of digits and whitespace are consistent regardless of (ASCII-compatible) encoding, but that's still just begging for issues. What are the semantics of the byte 0xA0 with respect to pretty-printing issues like linewraps? Are they consistent among all extant 8-bit encodings? What about bytes in 0x80..0x9F? What about 0x7F for that matter?

I won't say that ByteStrings should never be used for text (there are plenty of programs whose use of text involves only whitespace splitting and moving around the resultant opaque blobs of memory). But at a bare minimum, the use of ByteStrings for encoding text needs to be done via newtype wrapper(s) which keep track of the encoding. Especially for typeclass instances.

*shrug* this discussion on #haskell came about because lispy wanted to generate textual ByteStrings (using just ASCII) and would prefer not to have the overhead of Text. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

Jason Dagit

26 May 26 May

4:55 p.m.

On Wed, May 25, 2011 at 4:02 PM, Ivan Lazar Miljenovic wrote:

...

On 26 May 2011 08:49, wren ng thornton wrote:

...
On 5/25/11 1:03 PM, Bryan O'Sullivan wrote:

...
On Wed, May 25, 2011 at 5:59 AM, Ivan Lazar Miljenovic< ivan.miljenovic@gmail.com> wrote:

...
Well, using the Char8 version.

Just because you *could* do that, it doesn't mean that you *should*. It's a bad idea to use bytestrings for manipulating text, yet the only plausible reason to have wl-pprint handle bytestrings is so that they can be used as text.

It's worth highlighting that even with the Char8 version of ByteStrings you still run into encoding issues. Remember the days before Unicode came about? True, 8-bit encodings are often ASCII-compatible and therefore the representation of digits and whitespace are consistent regardless of (ASCII-compatible) encoding, but that's still just begging for issues. What are the semantics of the byte 0xA0 with respect to pretty-printing issues like linewraps? Are they consistent among all extant 8-bit encodings? What about bytes in 0x80..0x9F? What about 0x7F for that matter?

I won't say that ByteStrings should never be used for text (there are plenty of programs whose use of text involves only whitespace splitting and moving around the resultant opaque blobs of memory). But at a bare minimum, the use of ByteStrings for encoding text needs to be done via newtype wrapper(s) which keep track of the encoding. Especially for typeclass instances.

*shrug* this discussion on #haskell came about because lispy wanted to generate textual ByteStrings (using just ASCII) and would prefer not to have the overhead of Text.

Actually, I am okay with Text. My application is translating GHC Core to other languages. I may have misrepresented my position on IRC. Oops. In the case of GHC Core, all the unicode bytes are z encoded [1] away so that I'm certain to just have ascii bytes, and I don't think performance will be an issue. Being able to choose between String and Text in the same library is nice. Once you add support for letting the user specify their choice of String or Text, does it really cost that much to add ByteString? I think there are some cases where ByteString might make sense. Take darcs patches. Darcs does it's best to be encoding agnostic about patch hunk data, yet the syntax surrounding the hunk data is just ascii compatible bytes. Last time I checked, ByteString was still used to store the patch hunks as just a blob of bytes. You end up passing that to some pretty printer code when serializing it, even though you're doing your best not to dictate the encoding. I know darcs has had a lot of important utf-8 changes since I looked at the hunk representation code so what I said above may no longer be the case. Admittedly it's a rare case. Jason [1] http://hackage.haskell.org/package/zenc

Bryan O'Sullivan

25 May 25 May

12:58 p.m.

On Wed, May 25, 2011 at 5:01 AM, Ivan Lazar Miljenovic < ivan.miljenovic@gmail.com> wrote:

...

With my wl-pprint-text package, Jason Dagit suggested to me on #haskell that it would make sense to make such a pretty-printer be class-based so that the same API could be used for String, ByteString, Text, etc.

I don't think that's actually a good idea. The internals of your package will be a soggy mess, and the public APIs will be hard to follow. I'm also unclear on why you'd want to use something like wl-pprint for bytestrings at all.

5111

Age (days ago)

5112

Last active (days ago)

List overview

Download

16 comments

10 participants

participants (10)

Antoine Latter
Bryan O'Sullivan
Ivan Lazar Miljenovic
Jason Dagit
Johan Tibell
KQ
quick＠sparq.org
Simon Meier
Stephen Tetley
wren ng thornton