Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-toolchain, 2017-03-15

| Channels | #perl6-toolchain index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:44 Guest1864 joined #perl6-toolchain
06:15 domidumont joined #perl6-toolchain
06:57 domidumont joined #perl6-toolchain
09:12 domidumont joined #perl6-toolchain
10:03 lizmat joined #perl6-toolchain
12:35 domidumont joined #perl6-toolchain
12:41 domidumont joined #perl6-toolchain
14:45 ugexe Consider a distribution with META6 `:name<Foo::Bar>:ver<*>` that is installed via CURI. Now consider the author has changed their META6 to `:name<Foo-Bar>:ver<*>` but has left the `provides` field the same. Both of these supply the *module* "Foo::Bar:ver<*>". If you now install the one with the updated name it will naturally install ok (new name = new identity, so its not really installed and doesn't
14:45 ugexe require force).
14:45 ugexe well, it doesn't install ok. I mean it installs ok *up until precomp*.
14:46 ugexe At that point I believe the two distributions get mixed up and precomp errors occur
14:47 ugexe https://github.com/ugexe/zef/issues/139 (grep for "===SORRY!===" for the bit related to this)
14:49 ugexe in this case Perl6 Parser changed its distribution name from Perl6-Parser to Perl6::Parser. A zef bug attempts to install both for some reason, but the precomp bug is exposed because of it
14:51 ugexe I suspect its because of the `use My::Module::Util` using the first My::Module::Util it finds in CURI, even if that code is being run is a module in a distribution that includes a My::Module::Util
14:52 ugexe e.g. needing module loading to consider the current distribution first when choosing, or a `use My::Module::Util:from-my-own-distribution-only`
14:54 nine That way lies madness.
14:55 ugexe im not sure how it can be avoided
14:56 ugexe the auth/ver/api are the same. the module *names* are the same. only the distribution name changed
14:56 ugexe (the module code changed as well)
14:58 nine Different code for the same version? Sounds like the author screwed up
14:59 ugexe I agree, but I also understand how it could be considered OK it *does* generated a different distribution id due to having a different name
15:00 ugexe because this situation could very well be caused by two different authors who happen to converge on the same version at some point while also having a module with the same name
15:02 nine Then they should still have different auths
15:03 ugexe The only other solution I can think of is to abort install, like when installing a *distribution* thats already installed, if any modules match the *full* identity of any installed modules
15:03 nine And the idea has been from the start that people must be very specific when loading modules
15:03 ugexe e.g. expanding provides Foo::Bar to Foo::Bar:ver<$dist.ver>:auth<$dist.auth>
15:04 ugexe and checking all of provides to see if already installed
15:11 ugexe That seems like a decent option... iterating over all installed distribution's `provides` shouldn't have *that* much overhead in the context of installation
15:15 nine At least a warning may help raise awareness of this issue
15:23 ugexe why a warning and not a failure requesting the use of --force?
15:24 nine It's only an issue if differing source carries the same identity, isn't it?
15:24 ugexe I'm just trying to figure out what belongs in CURI and what belongs in zef to convey what is going on
15:25 ugexe they have different *distribution* identity
15:25 ugexe $dist-name =~ s/-/::/
15:26 ugexe but the `provides` module identities are the same yes
15:26 ugexe (distribution.name is not used in the module identity in any way)
17:28 domidumont joined #perl6-toolchain
18:44 domidumont joined #perl6-toolchain
19:52 lizmat joined #perl6-toolchain
20:45 domidumont joined #perl6-toolchain

| Channels | #perl6-toolchain index | Today | | Search | Google Search | Plain-Text | summary