GNU bug report logs -
#52152
Haskell Hackage importer can create dependency cycles
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 52152 in the body.
You can then email your comments to 52152 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org
:
bug#52152
; Package
guix
.
(Sun, 28 Nov 2021 02:51:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
John Kehayias <john.kehayias <at> protonmail.com>
:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org
.
(Sun, 28 Nov 2021 02:51:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hello,
While working on importing a bunch of Haskell packages, I came across a cycle created by the importer (twice actually, but forgot the other one). Perhaps this is from the metadata from Hackage, as it doesn't create the cycle when importing from Stackage. Here are the outputs:
guix import hackage tuple -r
Starting download of /tmp/guix-file.emhMwD
From https://hackage.haskell.org/package/tuple/tuple-0.3.0.2.tar.gz...
…0.2.tar.gz 19KiB 5.5MiB/s 00:00 [##################] 100.0%
Starting download of /tmp/guix-file.uzGEcb
From https://hackage.haskell.org/package/OneTuple/OneTuple-0.3.1.tar.gz...
….3.1.tar.gz 5KiB 3.1MiB/s 00:00 [##################] 100.0%
(define-public ghc-onetuple
(package
(name "ghc-onetuple")
(version "0.3.1")
(source
(origin
(method url-fetch)
(uri (string-append
"https://hackage.haskell.org/package/OneTuple/OneTuple-"
version
".tar.gz"))
(sha256
(base32 "1vry21z449ph9k61l5zm7mfmdwkwszxqdlawlhvwrd1gsn13d1cq"))))
(build-system haskell-build-system)
(inputs (list ghc-hashable ghc-base-orphans))
(native-inputs (list ghc-onetuple ghc-onetuple))
(arguments
`(#:cabal-revision
("2" "0gk0656igxl0km9kgh8v7b5vq74kla59ka9hvpzq57njr6bc0j58")))
(home-page "http://hackage.haskell.org/package/OneTuple")
(synopsis "Singleton Tuple")
(description
"This package is a compatibility package for a singleton data type . > data Solo a = Solo a . Note: it's not a @newtype@ . @Solo@ is available in @base-4.16@ (GHC-9.2).")
(license license:bsd-3)))
(define-public ghc-tuple
(package
(name "ghc-tuple")
(version "0.3.0.2")
(source
(origin
(method url-fetch)
(uri (string-append
"https://hackage.haskell.org/package/tuple/tuple-"
version
".tar.gz"))
(sha256
(base32 "094nx29aahyrvbcn7yca9zs2a5rxz1is7510w1q43rpvza7hdjrg"))))
(build-system haskell-build-system)
(inputs (list ghc-onetuple))
(home-page "http://hackage.haskell.org/package/tuple")
(synopsis "Various functions on tuples")
(description
"Various useful functions on tuples, overloaded on tuple size.")
(license license:bsd-3)))
The above has the cycle (twice!) in ghc-onetuple. Doing the same import from Stackage is more sane:
guix import stackage tuple -r
Starting download of /tmp/guix-file.EvZM8X
From https://hackage.haskell.org/package/tuple/tuple-0.3.0.2.tar.gz...
…0.2.tar.gz 19KiB 4.7MiB/s 00:00 [##################] 100.0%
Starting download of /tmp/guix-file.zMsjqd
From https://hackage.haskell.org/package/OneTuple/OneTuple-0.2.2.1.tar.gz...
…2.2.1.tar.gz 3KiB 3.2MiB/s 00:00 [##################] 100.0%
(define-public ghc-onetuple
(package
(name "ghc-onetuple")
(version "0.2.2.1")
(source
(origin
(method url-fetch)
(uri (string-append
"https://hackage.haskell.org/package/OneTuple/OneTuple-"
version
".tar.gz"))
(sha256
(base32 "15ls6kkf953288q7rsc49bvw467ll4nq28hvsgbaazdn7hf75ixc"))))
(build-system haskell-build-system)
(arguments
`(#:cabal-revision
("1" "03mygfz7lv6h0i30bq2grvmahbg9j7a36mc0wls2nr81dv9p19s7")))
(home-page "http://hackage.haskell.org/package/OneTuple")
(synopsis "Singleton Tuple")
(description
"This package provides a singleton tuple data type . > data OneTuple a = OneTuple a . Note: it's not a @newtype@")
(license license:bsd-3)))
(define-public ghc-tuple
(package
(name "ghc-tuple")
(version "0.3.0.2")
(source
(origin
(method url-fetch)
(uri (string-append
"https://hackage.haskell.org/package/tuple/tuple-"
version
".tar.gz"))
(sha256
(base32 "094nx29aahyrvbcn7yca9zs2a5rxz1is7510w1q43rpvza7hdjrg"))))
(build-system haskell-build-system)
(inputs (list ghc-onetuple))
(home-page "http://hackage.haskell.org/package/tuple")
(synopsis "Various functions on tuples")
(description
"Various useful functions on tuples, overloaded on tuple size.")
(license license:bsd-3)))
John
Information forwarded
to
bug-guix <at> gnu.org
:
bug#52152
; Package
guix
.
(Tue, 08 Mar 2022 10:23:03 GMT)
Full text and
rfc822 format available.
Message #8 received at 52152 <at> debbugs.gnu.org (full text, mbox):
Hi,
On dim., 28 nov. 2021 at 02:50, John Kehayias <john.kehayias <at> protonmail.com> wrote:
> While working on importing a bunch of Haskell packages, I came across
> a cycle created by the importer (twice actually, but forgot the other
> one). Perhaps this is from the metadata from Hackage, as it doesn't
> create the cycle when importing from Stackage. Here are the outputs:
The difference comes from upstream:
- hackage fetches from
https://hackage.haskell.org/package/OneTuple/OneTuple-0.3.1.tar.gz
- stackage fetches from
https://hackage.haskell.org/package/OneTuple/OneTuple-0.2.2.1.tar.gz
Therefore, it is not the same version. Let compare:
--8<---------------cut here---------------start------------->8---
$ guix import hackage OneTuple
Starting download of /tmp/guix-file.7VmwVe
From https://hackage.haskell.org/package/OneTuple/OneTuple-0.3.1.tar.gz...
….3.1.tar.gz 5KiB 3.8MiB/s 00:00 [##################] 100.0%
(package
(name "ghc-onetuple")
(version "0.3.1")
[...]
(base32 "1vry21z449ph9k61l5zm7mfmdwkwszxqdlawlhvwrd1gsn13d1cq"))))
[...]
(inputs (list ghc-hashable ghc-base-orphans))
(native-inputs (list ghc-onetuple ghc-onetuple))
(arguments
`(#:cabal-revision
("2" "0gk0656igxl0km9kgh8v7b5vq74kla59ka9hvpzq57njr6bc0j58")))
[...]
(description
"This package is a compatibility package for a singleton data type . > data Solo
a = Solo a . Note: it's not a @newtype@ . @Solo@ is available in @base-4.16@
(GHC-9.2).")
$ guix import stackage OneTuple
Starting download of /tmp/guix-file.WpQBJV
From https://hackage.haskell.org/package/OneTuple/OneTuple-0.2.2.1.tar.gz...
…2.2.1.tar.gz 10.9MiB/s 00:00 | 3KiB transferred
(package
(name "ghc-onetuple")
(version "0.2.2.1")
[...]
(base32 "15ls6kkf953288q7rsc49bvw467ll4nq28hvsgbaazdn7hf75ixc"))))
[...]
(arguments
`(#:cabal-revision
("1" "03mygfz7lv6h0i30bq2grvmahbg9j7a36mc0wls2nr81dv9p19s7")))
[...]
(description
"This package provides a singleton tuple data type . > data OneTuple a = OneTuple
a . Note: it's not a @newtype@")
--8<---------------cut here---------------end--------------->8---
And the "cycle" seems expected from OneTuple.cabal:
--8<---------------cut here---------------start------------->8---
$ cat OneTuple-0.3.1/OneTuple.cabal
cabal-version: >=1.10
[...]
test-suite th
type: exitcode-stdio-1.0
default-language: Haskell98
hs-source-dirs: test
main-is: th.hs
build-depends:
base
, OneTuple
, template-haskell
--8<---------------cut here---------------end--------------->8---
Well, for what they are worth, based on this remark, two points:
1. I do not know what could be done on Guix side. An idea?
2. Usually, it is recommended to follow LTS and so Stackage.
Cheers,
simon
Information forwarded
to
bug-guix <at> gnu.org
:
bug#52152
; Package
guix
.
(Thu, 07 Apr 2022 07:55:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 52152 <at> debbugs.gnu.org (full text, mbox):
Hi,
On Tue, 08 Mar 2022 at 11:04, zimoun <zimon.toutoune <at> gmail.com> wrote:
> On dim., 28 nov. 2021 at 02:50, John Kehayias <john.kehayias <at> protonmail.com>
> wrote:
>
>> While working on importing a bunch of Haskell packages, I came across
>> a cycle created by the importer (twice actually, but forgot the other
>> one). Perhaps this is from the metadata from Hackage, as it doesn't
>> create the cycle when importing from Stackage. Here are the outputs:
>
> The difference comes from upstream:
>
> - hackage fetches from
> https://hackage.haskell.org/package/OneTuple/OneTuple-0.3.1.tar.gz
> - stackage fetches from
> https://hackage.haskell.org/package/OneTuple/OneTuple-0.2.2.1.tar.gz
>
> Therefore, it is not the same version. Let compare:
[...]
> And the "cycle" seems expected from OneTuple.cabal:
>
> $ cat OneTuple-0.3.1/OneTuple.cabal
> cabal-version: >=1.10
>
> [...]
>
> test-suite th
> type: exitcode-stdio-1.0
> default-language: Haskell98
> hs-source-dirs: test
> main-is: th.hs
> build-depends:
> base
> , OneTuple
> , template-haskell
>
>
> Well, for what they are worth, based on this remark, two points:
>
> 1. I do not know what could be done on Guix side. An idea?
> 2. Usually, it is recommended to follow LTS and so Stackage.
I do not think it is a bug from Guix but a bug from OneTuple upstream,
not in their version 0.2.2.1, and introduce by their version 0.3.1.
We could introduce a detection for cycles. But nothing is broken or
raise a Backtrace. Somehow, the importers are some helper and not
bullet-proof one-to-one mapping, IMHO.
I propose to close this bug if no more idea. WDYT?
Cheers,
simon
Information forwarded
to
bug-guix <at> gnu.org
:
bug#52152
; Package
guix
.
(Thu, 07 Apr 2022 08:13:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 52152 <at> debbugs.gnu.org (full text, mbox):
Hi
On Thu, 7 Apr 2022, at 09:45, zimoun wrote:
> On Tue, 08 Mar 2022 at 11:04, zimoun <zimon.toutoune <at> gmail.com> wrote:
>> And the "cycle" seems expected from OneTuple.cabal:
>>
>> $ cat OneTuple-0.3.1/OneTuple.cabal
>> cabal-version: >=1.10
>>
>> [...]
>>
>> test-suite th
>> type: exitcode-stdio-1.0
>> default-language: Haskell98
>> hs-source-dirs: test
>> main-is: th.hs
>> build-depends:
>> base
>> , OneTuple
>> , template-haskell
>>
>>
>> Well, for what they are worth, based on this remark, two points:
>>
>> 1. I do not know what could be done on Guix side. An idea?
>> 2. Usually, it is recommended to follow LTS and so Stackage.
>
> I do not think it is a bug from Guix but a bug from OneTuple upstream,
> not in their version 0.2.2.1, and introduce by their version 0.3.1.
I don't think that's correct. My understanding is that it is common (perhaps even necessary) to include the library itself in the test-suite dependencies. For instance, the same thing appears in attoparsec. However, when importing attoparsec, they are filtered out, and indeed we even have functionality to filter out the package name [0], but for some reason that doesn't work for OneTuple.
0: https://git.savannah.gnu.org/cgit/guix.git/tree/guix/import/hackage.scm#n225
Reply sent
to
Lars-Dominik Braun <lars <at> 6xq.net>
:
You have taken responsibility.
(Tue, 07 Jun 2022 07:32:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
John Kehayias <john.kehayias <at> protonmail.com>
:
bug acknowledged by developer.
(Tue, 07 Jun 2022 07:32:02 GMT)
Full text and
rfc822 format available.
Message #19 received at 52152-done <at> debbugs.gnu.org (full text, mbox):
Hi,
this issue has been fixed in commit dedfcaa8e2b948124f76121b9062c827fe649e29.
Cheers,
Lars
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Tue, 05 Jul 2022 11:24:10 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 294 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.