pack_install does two things

[Anniepoo]

pack_install registers packs with the swi-prolog.org website when they're first installed.

This is a royal pain for pack developers. Usually one has some struggles getting proper pack zip file structure, etc etc and each time one attempts that final pack_install step it contaminates the version number. There needs to be a way to make it possible for pack developers to try before they buy.

Additionally, it's confusing for first time pack developers that pack_install does something besides install the pack on their local machine.

I propose pack_try/1, which does all the steps of pack_install except for installing locally and announcing to the outside world. If pack_try/1 succeeds, pack_register/1 would be guaranteed to succeed.

[wouterbeek]

@Anniepoo Would I correctly paraphrase your request as "Add the option to install a SWI pack locally during pack development"?

[JanWielemaker]

Note that you can easily do that by installing from a local directory or archive file. So, to develop a pack

• Make a directory with the name of the pack
• Realise the pack in there, including the prolog dir and pack.pl file
• Run ?- pack_install(packdir)., uninstall and install the pack until you are happy.
• Then make it available from a public place and install it to be registered.

[wouterbeek]

@JanWielemaker Then this turns into a documentation issue. I'll update the Pack docs with the intended workflow you describe.

[Anniepoo]

Can this method then assure that the pack will:

a) appear properly on the list of packs page when it's downloaded for the first time? (eg we've seen issues with different implementations of zip) b) install properly for users?

I'd just suggest that a separate predicate for a separate action is called for - publish_pack/1 would install the pack and publish it if necessary. install_pack/1 would only install

[wouterbeek]

@Anniepoo Your points (a) and (b) seem to be different issues? Can you open a separate issue for the ZIP thing?

@JanWielemaker I believe that Annie's request to use a different predicate name in order to denote an different step in the workflow you outlined above makes sense. Do you agree? Developers would use install_pack/1 in the local workflow and would use publish_pack/1 once they're done.

[Anniepoo]

We want developers to be in control of when the pack is published, so yup, two predicates.

It also gives us a roadmap for improvement - publish_pack can always have more preflight code added and doesn't have strict backwards compatibility requirements. install_pack needs to be happier installing some pack from an old version of the pack protocol.

If we add a pack protocol version check to the swi-prolog.org end code, we can someday add a check for version to the protocol code.

So architecturally, I think it's a good, simple to implement solution.