guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 2/2] gnu: Add python-kivy


From: Mark H Weaver
Subject: Re: [PATCH 2/2] gnu: Add python-kivy
Date: Sat, 13 Aug 2016 05:27:59 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

Dylan Jeffers <address@hidden> writes:

> Mark H Weaver <address@hidden> wrote:
>> We generally prefer to use tarball releases, unless there is a
>> compelling reason to use a non-release commit.
>> 
>> Is there a compelling reason?  If not, please use the 1.9.1 release
>> tarball from <https://github.com/kivy/kivy/archive/1.9.1.tar.gz>,
>> along with the 'file-name' field.
>
> Yes, the new dev version of kivy has a number of important enhancements
> that are not available in 1.9.1.

Can you be more specific?  Other popular distros, including Debian sid,
Ubuntu yakkety, Arch, and Gentoo, are all using version 1.9.1.  Kivy's
own PPA for "stable builds" uses a version from February, not long after
the 1.9.1 release.

Unless there are specific and compelling reasons why the latest release
is inadequate for most users, I'd be inclined to use the release
version, at least by default for the package named "python-kivy".

However, we could also add a "python-kivy-next" package for those who
want the latest and greatest from the upstream git repository.  We've
done that for some other packages, such as "guile-next" and
"geiser-next".

Would this work for you?

If we did this, the best way would be for the "python-kivy-next" package
to inherit from "python-kivy", but overridding the 'source' field, so it
would look something like this (untested):

--8<---------------cut here---------------start------------->8---
(define-public python-kivy
  (package
    (name "python-kivy")
    (version "1.9.1")
    (source
     (origin
       (method url-fetch)
       (uri (string-append "https://github.com/kivy/kivy/archive/";
                           version ".tar.gz"))
       (file-name (string-append name "-" version ".tar.gz"))
       (sha256
        (base32
         "0zk3g1j1z0lzcm9d0k1lprrs95zr8n8k5pdg3p5qlsn26jz4bg19"))))
    ...))

(define-public python2-kivy
  (package-with-python2 python-kivy))

(define-public python-kivy-next
  (let ((commit "a988c5e7a47da56263ff39514264a3de516ef2fe")
        (revision "1"))
    (package (inherit python-kivy)
      (name "python-kivy-next")
      (version (string-append "1.9.1-" revision "."
                              (string-take commit 7)))
      (source
       (origin
         (method git-fetch)
         (uri (git-reference
               (url "https://github.com/kivy/kivy";)
               (commit commit)))
         (file-name (string-append name "-" version "-checkout"))
         (sha256
          (base32
           "0jk92b4a8l7blkvkgkjihk171s0dfnq582cckff5srwc8kal5m0p")))))))

(define-public python2-kivy-next
  (package-with-python2 python-kivy-next))
--8<---------------cut here---------------end--------------->8---

The code above also takes into account some other issues which I explain
below.

> Also I believe I modified my email client (claws) to use UTF-8.
> Let me know if it is working for you.

The inline text of your email now specifies UTF-8 encoding (via a
"Content-Type: text/plain; charset=UTF-8" header), but the attachment
lacks the "charset=UTF-8" part of that header, so it's still not
working.  Anyway, I can fix it up by hand for now.

> +(define-public python-kivy
> +  (let ((commit
> +         "a988c5e7a47da56263ff39514264a3de516ef2fe"))
> +    (package
> +      (name "python-kivy")
> +      (version "1.9.1-dev")

Please see section 7.6.3 (Version Numbers) in the Guix manual,
specifically our conventions about version numbers for VCS snapshots,
and the recommended code structure to generate them.  I've done this in
my suggested definition of "python-kivy-next" above.

> +      (source
> +       (origin
> +         (method git-fetch)
> +         (uri (git-reference
> +               (url "https://github.com/kivy/kivy";)
> +               (commit commit)))
> +         (file-name (string-append name "-" version ".tar.gz"))

This 'file-name' field above is appropriate for a gzipped tarball
release, but not for a git checkout, because a git checkout becomes a
directory in the store.  So, for a git checkout, it should be something
like this:

         (file-name (string-append name "-" version "-checkout"))

Can you send an updated patch?  Thanks for bearing with me.  I think
we're getting close :)

     Thanks,
       Mark



reply via email to

[Prev in Thread] Current Thread [Next in Thread]