|
Fire is step THREE! | github.com/perl6/toolchain-bikeshed | Channel logs: irclog.perlgeek.de/perl6-toolchain/today | useful prior art: metacpan.org/pod/CPAN::Meta::Spec Set by moderator on 14 March 2017. |
|||
|
00:44
Guest1864 joined
06:15
domidumont joined
06:57
domidumont joined
09:12
domidumont joined
10:03
lizmat joined
12:35
domidumont joined
12:41
domidumont joined
|
|||
| 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 | |
| require force). | |||
| well, it doesn't install ok. I mean it installs ok *up until precomp*. | |||
| At that point I believe the two distributions get mixed up and precomp errors occur | 14:46 | ||
| github.com/ugexe/zef/issues/139 (grep for "===SORRY!===" for the bit related to this) | 14:47 | ||
| 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:49 | ||
| 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:51 | ||
| 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:52 | ||
| nine | That way lies madness. | 14:54 | |
| ugexe | im not sure how it can be avoided | 14:55 | |
| the auth/ver/api are the same. the module *names* are the same. only the distribution name changed | 14:56 | ||
| (the module code changed as well) | |||
| nine | Different code for the same version? Sounds like the author screwed up | 14:58 | |
| 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 | 14:59 | |
| 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:00 | ||
| nine | Then they should still have different auths | 15:02 | |
| 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 | ||
| ugexe | e.g. expanding provides Foo::Bar to Foo::Bar:ver<$dist.ver>:auth<$dist.auth> | ||
| and checking all of provides to see if already installed | 15:04 | ||
| 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:11 | ||
| nine | At least a warning may help raise awareness of this issue | 15:15 | |
| ugexe | why a warning and not a failure requesting the use of --force? | 15:23 | |
| 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 | ||
| they have different *distribution* identity | 15:25 | ||
| $dist-name =~ s/-/::/ | |||
| but the `provides` module identities are the same yes | 15:26 | ||
| (distribution.name is not used in the module identity in any way) | |||
|
17:28
domidumont joined
18:44
domidumont joined
19:52
lizmat joined
20:45
domidumont joined
|
|||