Symlinks in juju-core

[roger peppe]

ISTR adding the symlinks, and i'm pretty sure that was because
some things use the default series when deploying testing
charms.

maybe it's no longer true. i'd be happy to avoid all use
of symlinks in our code base.

next up: appropriate use of path/filepath :-)

On 7 February 2013 14:12, William Reade <william.reade at canonical.com> wrote:
> On Thu, 2013-02-07 at 16:04 +0400, John Arbash Meinel wrote:
>> ...
>> >> Is that reasonable? The alternative is to have it try to symlink
>> >> if it can, and then fall back to directory copies. Which would
>> >> let you use symlinks if the platform supports it.
>>
>> ...
>>
>> > That is, we're probably copying everything that matters anyway, and
>> > what we're not copying we probably should be; so, I wouldn't expect
>> > the difference made by a few extra copies in a few extra cases to
>> > be significant, and I think I would willingly pay a small
>> > performance cost in exchange for simple cross-platform tests.
>> >
>> > Cheers William
>>
>> I removed the symlinks, and 'go test ./...' passes. (I had a test fail
>> here and there, but nothing reproducible, so I think those are just
>> unstable tests.)
>
> I'm sure that at least some test should fail... perhaps one involving
> default-series? Perhaps there is one, but it isn't affected because it
> explicitly copies from series into the appropriate subdir of a
> locally-built repository. Does this ring any bells with anyone?
>
>> I did try removing the whole directory and tests failed. Digging
>> further it looks like "testing.Charms.Bundle*" functions moderate
>> access to the actual charms, and take a series parameter. However all
>> callers pass the string "series" rather than an actual series.
>
> If my above supposition holds, and it is really the case that there are,
> no actual clients using the functionality, I'm +1 on dropping both the
> symlinks and the parameter... but I am also growing increasingly
> convinced that they were put there for a reason by someone still on the
> team, and that we should be able to ferret out their meaning before we
> discard them.
>
>> So removing them seems fine. The only remaining pieces is that there
>> is a symlink in the 'dummy' charm, which I imagine is to make sure
>> symlinks get treated correctly when bundling charms. So that is
>> something I'll look to make lazy created, and skip those tests on
>> platforms that don't support symlinks.
>
> Assuming the foregoing, +1.
>
> Cheers
> William
>
>
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev