librelist archives

« back to archive

Rolling back profile-scoped target isolation

Rolling back profile-scoped target isolation

From:
Phil Hagelberg
Date:
2013-08-18 @ 04:35
Hello folks.

Leiningen 2.3.0[1] introduced a feature called profile-scoped target
isolation where the target path that Leiningen would use (and thus where
it would store class files, extracted native components, and other
generated artifacts) would vary based on which profiles were active at
any given time.

While this solves a lot of common headaches (especially around AOT
"leaking" where it shouldn't) and avoids subtle cases where user-level
dependencies sneak into downsteam artifacts, it seems to be a bit too
disruptive to include in a point release. In an ideal world, Leiningen
projects wouldn't care where generated files get written to--users
should never need to peer through that level of abstraction, but there
are definitely enough projects out there that work otherwise to justify
backing out this change until Leiningen 3.0, when users will be more
prepared for backwards-incompatible changes.

So, if you're a plugin developer: be aware that this functionality is
slated to become the default, and it's available to users of 2.x
already. Don't assume :target-path is "target" or even that it stays the
same for all task runs of a given project.

In fact; I would recommend users add :target-path "target/%s" to their
user profile. Leiningen 2.3+ will splice in a string uniquely
identifying the current profile into the %s placeholder when you use
non-default profiles. This lets you do neat things like:

    :profiles {:uberjar {:aot :all}}

and have full AOT happen when you create an uberjar without any of the
headaches of having stale .class files around during development.

I hope to have 2.3.2 released in a few days with this change along with
https://github.com/technomancy/leiningen/issues/1296, so if there's
anything else you think should be included please speak up.

cheers,
Phil

[1] - Technically this was introduced in 2.2.0, but there was a bug
which caused :compile-path and :native-path to not be relative to
:target-path, so the effects weren't seen until 2.3.0:

https://github.com/technomancy/leiningen/commit/53fdf1c685a1bfd1805b1274d7625686fe2fcabc