librelist archives

« back to archive

Re: [leiningen] :profiles documentation

Re: [leiningen] :profiles documentation

From:
Phil Hagelberg
Date:
2013-08-29 @ 00:14
Gregg Reynolds writes:

> The documentation says "By default the :dev, :provided, :user, :system, and
> :base profiles are activated for each task..."
>
> I'm having trouble seeing what the design point is.  If all five are always
> active for each task, then why have five distinct default profiles?

Mostly it comes down to where they are defined. The :base profile ships
with Leiningen itself. If it were called :dev instead, then every time a
project.clj file defined a :dev profile, it would shadow the built-in
one, and they wouldn't have access to nREPL, clojure-complete, etc.
Similarly the :user profile is specified in such a way it's applied
to every projects a given user works on, and :system can be specified in
/etc.

The :provided profile is the odd one out here and serves a different
purpose; see `lein help tutorial` for details.

> It also looks like :dev is synonymous with :test, or maybe it was meant to
> replace :test but some refs to :test are still in place.

No, :dev is for all development. The :test profile is only active during
the :test task.

> So :test and :production (and :repl, etc.) are hardcoded here, but not
> documented.

That place specifically is just whether to warn when a profile is
unknown. The :production profile is a special case in that it's
canonically empty (ideally production usage should be as if Leiningen
were not involved at all) but it can be populated in project.clj if
necessary. This also is mentioned in the tutorial, but not in
PROFILES.md.

> So here's a specific question:  I need to put some jars on the classpath
> for the test task only.  I can to this thusly:
>
>   :profiles {:test ...}
>
> But it also works if I use :dev instead of :test.  So my question is: what
> is the correct way to go?

Presumably you would want to be able to use these dependencies from the
repl, so the :dev profile would be best. The only use-case I can think
of for the :test profile would be more for if you want to isolate your
test DB from your regular dev one so that the tests are free to blow
everything away on every test run without disrupting scratch data you
use in the repl. Most of the time you should use :dev.

> I'd be happy to try to tweak the documentation if somebody can provide some
> guidance.

That would be great; thanks. Part of the problem is that there are
things documented in the tutorial that should also be mentioned in
PROFILES.md. At least it should say to refer to the tutorial in a few
places. But an overview of the purposes of the default profiles would be
great too.. We also don't document task-specific profiles very well. The
repl, test, and uberjar tasks each will check for profiles with the same
name and apply them during their operation.

-Phil

Re: [leiningen] :profiles documentation

From:
Gregg Reynolds
Date:
2013-08-29 @ 08:16
On Wed, Aug 28, 2013 at 7:14 PM, Phil Hagelberg <phil@hagelb.org> wrote:

>
> Gregg Reynolds writes:
>
...

> > So here's a specific question:  I need to put some jars on the classpath
> > for the test task only.  I can to this thusly:
> >
> >   :profiles {:test ...}
> >
> > But it also works if I use :dev instead of :test.  So my question is:
> what
> > is the correct way to go?
>
> Presumably you would want to be able to use these dependencies from the
> repl, so the :dev profile would be best. The only use-case I can think
> of for the :test profile would be more for if you want to isolate your
> test DB from your regular dev one so that the tests are free to blow
> everything away on every test run without disrupting scratch data you
> use in the repl.


Something like that.  Google App Engine's SDK includes a test environment
specifically designed for use in unit testing, so it's only useful with
:test.



> > I'd be happy to try to tweak the documentation if somebody can provide
> some
> > guidance.
>
> That would be great; thanks.


I got started, then remembered I'd forgotten I used to know quite a bit
about configuration - started out in mainframes and once worked as a
release engineer for a complex multi-platform piece of software.  So I
ended up sketching out a General Theory of Configuration.  You can see the
damage at https://github.com/greynolds/leiningen/doc/PROFILES.md, on branch
profiledoc.

Is it more or less accurate?

Cheers,

Gregg

Re: [leiningen] :profiles documentation

From:
Gregg Reynolds
Date:
2013-08-29 @ 08:17
Sorry, that should be
https://github.com/greynolds/leiningen/blob/profiledoc/doc/PROFILES.md



On Thu, Aug 29, 2013 at 3:16 AM, Gregg Reynolds <dev@mobileink.com> wrote:

> On Wed, Aug 28, 2013 at 7:14 PM, Phil Hagelberg <phil@hagelb.org> wrote:
>
>>
>> Gregg Reynolds writes:
>>
> ...
>
>> > So here's a specific question:  I need to put some jars on the classpath
>> > for the test task only.  I can to this thusly:
>> >
>> >   :profiles {:test ...}
>> >
>> > But it also works if I use :dev instead of :test.  So my question is:
>> what
>> > is the correct way to go?
>>
>> Presumably you would want to be able to use these dependencies from the
>> repl, so the :dev profile would be best. The only use-case I can think
>> of for the :test profile would be more for if you want to isolate your
>> test DB from your regular dev one so that the tests are free to blow
>> everything away on every test run without disrupting scratch data you
>> use in the repl.
>
>
> Something like that.  Google App Engine's SDK includes a test environment
> specifically designed for use in unit testing, so it's only useful with
> :test.
>
>
>
>> > I'd be happy to try to tweak the documentation if somebody can provide
>> some
>> > guidance.
>>
>> That would be great; thanks.
>
>
> I got started, then remembered I'd forgotten I used to know quite a bit
> about configuration - started out in mainframes and once worked as a
> release engineer for a complex multi-platform piece of software.  So I
> ended up sketching out a General Theory of Configuration.  You can see the
> damage at https://github.com/greynolds/leiningen/doc/PROFILES.md, on
> branch profiledoc.
>
> Is it more or less accurate?
>
> Cheers,
>
> Gregg
>