Re: Versioned Packagers (Iteration IV)

> 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. > > 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. Certainly there’s overlap between the two, but the first is a more low-level thing that doesn’t need worry itself about versioning let alone multiple simultaneous versions. I just don’t want to see the possibility of having basic “import” and “export” functionality crushed under the bikeshed while all the fine semantics of versioning are worked out. —c