Re: Versioned Packagers (Iteration IV)

Hi Chuck, > On Jul 4, 2024, at 11:05 AM, Chuck Adams <chaz@chaz.works> wrote: >> On Jul 3, 2024, at 6:16 PM, Michael Morris <tendoaki@gmail.com> wrote: >> >> Hello all. Hitting reset again as the primary problem at hand has become clear. Let's >> recap it. >> >> Autoloading is great for loading packages, but it can't load different versions of the >> same package at the same time. Why would you want to do that? >> >> When you don't have full control of the code.in >> >> For example, consider Drupal. It is running Twig at some version of 3 at the moment. >> Suppose Twig 4 is introduced with significant backward compatibility breaks (Not saying the authors >> would do such a thing) but also wonderful features. >> …[snip]... >> This is why I advocate a new keyword for this - import. Import’s behavior is most >> similar to require_once, but it doesn't have to be the same. Since it is a new entrypoint into >> the engine the way the engine considers the code can be different - whether slightly different or >> radically different is a debate for another time. I'm going to stick with only those changes >> that make sense in the context of package links. > > > I’m seeing a lot of conflation of ‘module’ and ‘package’ in these discussions, and to > me they mean different things: > > * A module is a sort of “first class namespace” that can export symbols and import others. > Think ES5 or python modules. If you don’t want it 1-1 with files, think Perl modules. > > * A package is an “installable” unit that provides modules, among other things. Packages > have metadata, the most important piece of which is a machine-readable version. Your definitions are language-specific. For example, in Go the definitions for those terms are the opposite of how you defined them. The point being that PHP is free to choose how they are defined with respect to PHP. To which I will add "as long as the terms are used consistently." -Mike