Re: “Packaging”

That’s my first post to this list, but I follow carefully all posts 
since the beginning.

I’ve spent a lot of time on these kinds of subjects, and there are 
points that seems important to me :

  *

    when my code requires a dependency, the dependency resolver *must*
    resolves to an unmodifiable file, and not to a source code file ; so
    we need a publish mecanism

  *

    dependency version number *should* be outside of my source code

  *

    dependency identification *should* be an URI, maybe relative,
    because we all have a URI resolver somewhere in our projects and
    this eases implementations to be pluged, if we do not have a
    standard way to do it

  *

    as Liam said, automatic installation and updates are great, but we
    *must* have a way to force - or to limit - our dependencies version
    resolves, at least to have a reproduceable build

There are a lot of dependency resolution mecanisms, already cited here : 
maven, npm, nuget, etc… I prefer the ones where external files are not 
copied to my project, and so have a local repository - I prefer Maven / 
Docker way to Npm way. But this requires to rely on something external 
to XML world. In fact, xpath, xquery or xslt are not standalone 
executables, and all need an external processor. So it is this 
processor’s responsability to resolve dependencies.

But yes, we need a standard way to do it, and we must not re-create the 
wheel. So it’d be better to re-use an existing repository mecanism. I’d 
be happy to help on this.

Best regards,
Christophe

Le 11/11/2023 à 10:05, Liam R. E. Quin a écrit :

> On Fri, 2023-11-10 at 17:12 +0000, Christian Grün wrote:
>> Hi Norm,
>>
>> I think I agree with all your observations: It feels essential to
>> have a unified packaging mechanism; both implementors, contributors
>> and developers would benefit a lot from it.
> The main thing i want from a packaging mechanism, and that needs to be
> incorporated into the planning early on, is automatic installation.
>
> This was a LARGE part of the success of Perl, and of TeX, in their
> respective successful periods, and it's helped Python and node and Rust
> and other languages.
>
> Automatic installation needs to include
> * automatic dependency installation, optionally interactively
> * automatic package updates
> * easy deployment of software that uses packages
>
> One way to do this is to have a package that provides a way to install
> packages. This is e.g. how Perl does it, with the CPAN module.
>
> It's not clear to me we need a single centralized repository - there
> could be a list, for example. Or packages could be downloaded from
> gitlab or github.
>
> Being able to install packages system-wide and on a per-user basis is a
> plus, but i think these days very minor. Per-user is sufficient.
>
> Hence, when Christian writes,
>
>> • have a central repository for downloading modules with a given path
> i agree that's paramount.
>
>> and
>> • address these modules with the existing XQuery “import module
>> namespace 'xyz';” statement.
>> • If an implementation exists for the URI in the processor, or if the
>> module has already been downloaded, the repository access can be
>> skipped.
> Optionally ;) as you might want to install a version with more features
> than the processor-provided one.
>
> Seems to me it should work for
> * standalone XPath files
> * XQuery
> * XSLT
> * maybe also XML catalogue files and dtd/schema collections
> * ancilliary files (e.g. an XSLT transformation might also use some CSS
> and JavaScript files as part of the output, and these need to be
> installed where the stylesheet can find them)
>
> For Linux systems (especially servers) the XDG spec is relevant in
> terms of where to put things; the location is determined by an
> environment variable.
>
> liam
>
>
​