pack_install does two things about swipl-devel HOT 6 OPEN

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

from swipl-devel.

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.

from swipl-devel.

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

from swipl-devel.

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

from swipl-devel.

@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.

from swipl-devel.

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.

from swipl-devel.