librelist archives

« back to archive

Profiles and :target-path

Profiles and :target-path

From:
Phil Hagelberg
Date:
2013-07-24 @ 17:15
Hello folks.

Despite things being fairly quiet recently, we are fairly close to a
release of Leiningen 2.3.0[1]. However, there's one lingering issue to
address first.

In 2.2.0 we added the feature to change :target-path based on the
currently-active profiles. The motivation here was that you could have
cross-contamination from :dev dependencies which could affect .class
files in target/classes and make their way into a release jar. So
:target-path now includes the names of currently-active profiles in
order to isolate each set of profiles.

The problem with this is that we either have to introduce a bit of
breakage by moving the default target path to "target/default" or
special-case the default profile, which would cause leakage between the
default profile and the "no profiles" case, which arguably defeats the
whole purpose of isolation.

This might not be a problem if people don't use the empty set of
profiles. Leiningen provides an empty-by-default "production" profile,
and the docs around stripping out default profiles all suggest using it
as far as I remember. So if everyone interested in stripping out
profiles just uses the production profile, this might not be a
problem. It would be clearer to change the default target path
to "target/default", but it would introduce some breakage around tools
which make assumptions rather than checking the actual location of
created files.

In 2.2.0 we had a special-case for the default profile that didn't
actually work reliably[2], so the current state of master is to use
"target/default". But I'm hesitant to release it that way.

Thoughts?

-Phil

[1] - 
https://github.com/technomancy/leiningen/issues?milestone=12&page=1&state=open
[2] - https://github.com/technomancy/leiningen/issues/1222

Re: [leiningen] Profiles and :target-path

From:
Eric Arthen
Date:
2013-07-24 @ 17:31
Phil,

Would this change all target directories or just when nothing was specified
in the project?

We have:  :compile-path "target/classes"  :target-path "target/"

So I'm assuming those would not have an extra path inserted, correct? Just
if we omitted those.

If it changed from "target" to "target/default" would break our build
system. (And as we always do clean first there is no danger of cross
contamination, but I can see the value on a development system that does
builds for multiple profiles).

Eric


On Wed, Jul 24, 2013 at 1:15 PM, Phil Hagelberg <phil@hagelb.org> wrote:

>
> Hello folks.
>
> Despite things being fairly quiet recently, we are fairly close to a
> release of Leiningen 2.3.0[1]. However, there's one lingering issue to
> address first.
>
> In 2.2.0 we added the feature to change :target-path based on the
> currently-active profiles. The motivation here was that you could have
> cross-contamination from :dev dependencies which could affect .class
> files in target/classes and make their way into a release jar. So
> :target-path now includes the names of currently-active profiles in
> order to isolate each set of profiles.
>
> The problem with this is that we either have to introduce a bit of
> breakage by moving the default target path to "target/default" or
> special-case the default profile, which would cause leakage between the
> default profile and the "no profiles" case, which arguably defeats the
> whole purpose of isolation.
>
> This might not be a problem if people don't use the empty set of
> profiles. Leiningen provides an empty-by-default "production" profile,
> and the docs around stripping out default profiles all suggest using it
> as far as I remember. So if everyone interested in stripping out
> profiles just uses the production profile, this might not be a
> problem. It would be clearer to change the default target path
> to "target/default", but it would introduce some breakage around tools
> which make assumptions rather than checking the actual location of
> created files.
>
> In 2.2.0 we had a special-case for the default profile that didn't
> actually work reliably[2], so the current state of master is to use
> "target/default". But I'm hesitant to release it that way.
>
> Thoughts?
>
> -Phil
>
> [1] -
> https://github.com/technomancy/leiningen/issues?milestone=12&page=1&state=open
> [2] - https://github.com/technomancy/leiningen/issues/1222
>



-- 
Eric Leventhal Arthen  |  Principal Software Engineer
Brightcove, Inc. http://www.brightcove.com/
earthen@brightcove.com

Re: [leiningen] Profiles and :target-path

From:
Phil Hagelberg
Date:
2013-07-24 @ 18:12
Eric Arthen writes:

> Would this change all target directories or just when nothing was specified
> in the project?
>
> We have:  :compile-path "target/classes"  :target-path "target/"
>
> So I'm assuming those would not have an extra path inserted, correct? Just
> if we omitted those.

Yeah, that's actually another bug that I'm in the middle of fixing;
:compile-path and :native-path need to be relative to
:target-path. It'll probably end up defaulting to "%s/classes" and then
normalized to have the current value of :target-path `format`ted into
it. Having :compile-path not change along with the profiles completely
defeats the purpose of profile isolation.

Of course; you can always provide your own :compile-path value that
doesn't include "%s" if you want to skip profile isolation; format will
simply discard the spliced value in this case.

> If it changed from "target" to "target/default" would break our build
> system. (And as we always do clean first there is no danger of cross
> contamination, but I can see the value on a development system that does
> builds for multiple profiles).

That's probably enough of a data point to stick with the
default-special-case for now; we can revisit it for 3.0.

-Phil

Re: [leiningen] Profiles and :target-path

From:
Laurent Petit
Date:
2013-07-24 @ 17:45
What about native deps, will they still be extracted in target/ directory?
Per profile (ick!)?

What about have them located in the local maven repo as are all the other
dependencies managed by aether ?(ok the last one is a little bit out of
topic)

Le mercredi 24 juillet 2013, Eric Arthen a écrit :

> Phil,
>
> Would this change all target directories or just when nothing was
> specified in the project?
>
> We have:  :compile-path "target/classes"  :target-path "target/"
>
> So I'm assuming those would not have an extra path inserted, correct? Just
> if we omitted those.
>
> If it changed from "target" to "target/default" would break our build
> system. (And as we always do clean first there is no danger of cross
> contamination, but I can see the value on a development system that does
> builds for multiple profiles).
>
> Eric
>
>
> On Wed, Jul 24, 2013 at 1:15 PM, Phil Hagelberg 
<phil@hagelb.org<javascript:_e({}, 'cvml', 'phil@hagelb.org');>
> > wrote:
>
>>
>> Hello folks.
>>
>> Despite things being fairly quiet recently, we are fairly close to a
>> release of Leiningen 2.3.0[1]. However, there's one lingering issue to
>> address first.
>>
>> In 2.2.0 we added the feature to change :target-path based on the
>> currently-active profiles. The motivation here was that you could have
>> cross-contamination from :dev dependencies which could affect .class
>> files in target/classes and make their way into a release jar. So
>> :target-path now includes the names of currently-active profiles in
>> order to isolate each set of profiles.
>>
>> The problem with this is that we either have to introduce a bit of
>> breakage by moving the default target path to "target/default" or
>> special-case the default profile, which would cause leakage between the
>> default profile and the "no profiles" case, which arguably defeats the
>> whole purpose of isolation.
>>
>> This might not be a problem if people don't use the empty set of
>> profiles. Leiningen provides an empty-by-default "production" profile,
>> and the docs around stripping out default profiles all suggest using it
>> as far as I remember. So if everyone interested in stripping out
>> profiles just uses the production profile, this might not be a
>> problem. It would be clearer to change the default target path
>> to "target/default", but it would introduce some breakage around tools
>> which make assumptions rather than checking the actual location of
>> created files.
>>
>> In 2.2.0 we had a special-case for the default profile that didn't
>> actually work reliably[2], so the current state of master is to use
>> "target/default". But I'm hesitant to release it that way.
>>
>> Thoughts?
>>
>> -Phil
>>
>> [1] -
>> https://github.com/technomancy/leiningen/issues?milestone=12&page=1&state=open
>> [2] - https://github.com/technomancy/leiningen/issues/1222
>>
>
>
>
> --
> Eric Leventhal Arthen  |  Principal Software Engineer
> Brightcove, Inc. http://www.brightcove.com/
> earthen@brightcove.com <javascript:_e({}, 'cvml',
> 'earthen@brightcove.com');>
>

Re: [leiningen] Profiles and :target-path

From:
Phil Hagelberg
Date:
2013-07-24 @ 18:15
Laurent PETIT writes:

> What about native deps, will they still be extracted in target/ directory?
> Per profile (ick!)?

Yeah, see my reply to Eric. We need to avoid letting dev dependencies
leak into actual releases.

> What about have them located in the local maven repo as are all the other
> dependencies managed by aether ?(ok the last one is a little bit out of
> topic)

Not a bad idea. Ideally we could collaborate upstream with the Aether
devs to get some kind of JVM-wide standard around native dependencies,
but I don't see anything conceptually wrong with extracting things into
~/.m2 (possibly handled by pomegranate?) even if this doesn't
happen. Native dependencies have historically been a weak point because
none of the core devs actually use them as far as I remember.

However, this is a separate concern and shouldn't block the release of 2.3.0.

-Phil