Custom management commands provided as only .pyc files?

[Stodge]

As explained in https://code.djangoproject.com/ticket/14952, Django doesn't support custom management commands that are only provided as .pyc files. I have a requirement with my project that I cannot distribute the .py files - only the .pyc. It's a roundabout way of not providing the source code when we install our software on a client's server. Is the only recommended way around this to hack django/core/management/init.py? Is it acceptable to monkey patch the file instead? I don't want to hack the Django source as it will break when I upgrade Django in the future. Thanks

[Christian Ledermann]

you can easily decompile pyc into py files
http://stackoverflow.com/questions/5287253/is-it-possible-to-decompile-a-compiled-pyc-file-into-a-py-file
so it doesn't protect your source code.

> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users...@googlegroups.com.
> To post to this group, send email to django...@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/6b8f36ee-3419-4af7-a46c-43236b8620b0%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Best Regards,

Christian Ledermann

London - UK
Mobile : +44 7474997517

<*)))>{

If you save the living environment, the biodiversity that we have left,
you will also automatically save the physical environment, too. But If
you only save the physical environment, you will ultimately lose both.

1) Don’t drive species to extinction

2) Don’t destroy a habitat that species rely on.

3) Don’t change the climate in ways that will result in the above.

}<(((*>

[Collin Anderson]

it seems to me it should be fair to distribute "in the clear" very minimal .py files that don't do anything besides call other code in your project.

[Russell Keith-Magee]

As it says on the ticket you reference, you shouldn't be thinking of .pyc files as "compiled" python. It's an internal cache of the runtime state of a particular interpreter. And even if you are able to avoid any cross machine architecture problems, you're really not providing that much protection, because it's easily to decompile PYC files back to source code. 

However, assuming you're going to ignore that advice... :-)

As I see it, you have four options:

 * Maintain a private fork of Django that handles PYC files the way you want, and merge any changes that are made to Django's trunk with your own fork whenever you want to make a release.

 * Maintain your own implementation of management commands. Remember, manage.py is just a python script, and it's under your control. If you want to change the entry point to point at your own handling of management commands, go right ahead. You may even find that you can crib *most* of the implementation from Django's own code, and only override a couple of key methods.

 * Find a different way to distribute your code. Think outside the box. Don't distribute a tarball of "compiled" code - distribute a virtual machine with an encrypted disk image. The end user then "runs" the virtual machine. Or distribute the code as a service - provide a service endpoint (under your control) that holds all the important data or algorithms, and the only thing you put on the end user's computer is a frontend that contains no useful IP. 

 * Use the legal approach. Distribute the Python code as Guido intended :-), but accompany it with a very clear usage agreement that says "you copy this code, and we send in the goon squad". Most businesses will be very careful if you make them sign a document like that.

Yours,

Russ Magee %-)

On Tue, Aug 12, 2014 at 9:55 PM, Stodge <sto...@gmail.com> wrote:

As explained in https://code.djangoproject.com/ticket/14952, Django doesn't support custom management commands that are only provided as .pyc files. I have a requirement with my project that I cannot distribute the .py files - only the .pyc. It's a roundabout way of not providing the source code when we install our software on a client's server. Is the only recommended way around this to hack django/core/management/init.py? Is it acceptable to monkey patch the file instead? I don't want to hack the Django source as it will break when I upgrade Django in the future. Thanks

--

[Javier Guerra Giraldez]

On Wed, Aug 13, 2014 at 3:59 AM, Russell Keith-Magee
<rus...@keith-magee.com> wrote:
> As I see it, you have four options:

there's also option #2.5:

* distribute .pyc files as required, but include a call to uncompyle2
(or any alternative .pyc to .py decoder) at setup time, so Django
finds the .py files as usual.


it not only follows the letter of the requirement ("thou shalt not
give your .py files unto others"), but highlights how inappropriate it
is.


--
Javier

[Collin Anderson]

 * distribute .pyc files as required, but include a call to uncompyle2
(or any alternative .pyc to .py decoder) at setup time, so Django
finds the .py files as usual.

Brilliant! Or, even just have setup write out the stub .py files without needing another dependency.

[Stodge]

Thanks - there are some great suggestions here. Much appreciated.