Discussion
Evgeny Shvarov · Mar 4, 2021

Deploying Packages Without Source Code - commercial mode. Do we need it?

Hi Developers!

Thank you for using ZPM Package Manager and contributing more and more useful packages to the public registry!

But as you already aware ZPM packages are always deployed with source code.

Do you think we need to add the option to deploy without source code - e.g. if you want to deploy a commercial package?

Will you develop commercial modules if there will be an option and deploy it with ZPM?

How do you deploy commercial applications today?

Should we add the option to deploy ZPM modules without source code

Register or login to poll

Results
80%
(8)
Yes, it's a great option for commercial use
10%
(1)
No, I'd never install a module without a source code
10%
(1)
No, There is no such need for modules, it's an application story
30
3 0 10 131
Log in or sign up to continue

Replies

if the deployment is sensitive distribution happens a pure  *.OBJ

@Evgeny Shvarov there's internal work in the HS package manager to support packaging as a studio project, which may optionally include deployed code. (I believe this didn't make it into the ZPM fork.)

The downside to this approach is that you may need different artifacts for different target platform versions. (It's always safest to assume that you do, at least on the major.minor level.) This would be a new design consideration in zpm-registry.

One possible upside to this approach is that it may be possible to install the build artifact even on environments that don't have the package manager. For the internal implementation we generate an INSTALL.mac that automates things from the different resource processor classes. Uninstallation is still a bit of a conundrum though; I think we'd be better off requiring the package manager for any ZPM implementation of packaging/installing deployed code.

I can think of one extremely valuable internal project that would only be palatable to distribute via ZPM if we didn't have to ship all the source (specifically, a Mockito-style mock framework for ObjectScript that breaks the glass on some internal things not shipped in product source).

I'll add - it should be an option (and in the HS package manager it is) to distribute some classes/routines as .OBJ and some with source within the same package.

thank you, Tim! This is very helpful

Deployed classes still have to be delivered but without code, for sure, with just compiled OBJ code.

if we deliver .obj file - is it enough?

Definitions might be wrapped into some $$$macro that calls the .INT directly.
Similar to some compiled class . Deployed classes provide more comfort.

When I worked with TrakCare, I remember that TrakCare classes had only the ClassMethod signatures and the obj file.

We could always find out which ClassMethod we have available, but we should never compile them! laugh