* Package name    : cask
  Version         : 0.8.0
  Upstream Author : Johan Andersson <johan.rejeep@gmail.com> and others
* URL             : https://github.com/cask/cask/
* License         : GPL-3+
  Programming Lang: Emacs Lisp, Python, etc.
  Description     : project management tool for Emacs

Cask is a project management tool for Emacs that helps automate the package
development cycle; development, dependencies, testing, building, packaging
and more.

Cask can also be used to manage dependencies for your local Emacs configuration.

Cask is used by many (not but some?) Emacs Lisp projects.

Hi Lev,

I asked Sean about packaging Cask this September as part of my
investigation into enabling elpy/ert-runner/commander-el's selftests.
This was on #debian-emacs

He NACKed it, saying we need to adapt packages to dh-elpa, and that
its ert support provides this functionality.

For learn-by-example, my hope is that elpy, ert-runner, and/or
commander-el will be useful, once I complete the work.  Failing that,
do you think there will be a need to document how to adapt packages
that use Cask to dh-elpa tests?

Sean, I've CCed you so you can confirm that if this bug should be
closed.

Cheers!
Nicholas

Hello Nicholas, Lev,

Yes.  Cask should never be a build-dependency, or dependency, of any
elpa-* packages.  It is always possible to cut it out of the package
build.  Avoiding Cask was the one reason why I wrote dh_make_elpa.

It is rare that you need significant work to remove Cask.  Usually, you
can just do something like this to turn it off:

    override_dh_auto_build:
    	/bin/true

Then dh_elpa_test is smart enough to run the tests anyway.  You may need
to add some lines to d/elpa-test, and upstream's Cask
configuration and/or Makefile can help you figure out what to add.

For an example of an upstream that uses Cask, where it was bypassed, see
the flycheck source package.  As you can see, it's not complicated.

Of course, it might still be desirable to package Cask as a tool for
users who are developing Emacs Lisp packages.  So this RFP could remain
open for that purpose.  But it should definitely not be a build
dependency.

(I've added a note about this to our team's wiki)

Hello,

was one reason*

Tagging this bug 'moreinfo' to indicate that clarity is needed regarding
whether the RFS is for Cask as a build-dependency or as an enduser tool.

Hi,

Пт 06 окт 2017 @ 00:10 Sean Whitton <spwhitton@spwhitton.name>:

I completely agree with your point.

Agreed.

Cheers!
Lev