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 > > -- > 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+unsubscr...@googlegroups.com. > To post to this group, send email to django-users@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 > <https://groups.google.com/d/msgid/django-users/6b8f36ee-3419-4af7-a46c-43236b8620b0%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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+unsubscr...@googlegroups.com. To post to this group, send email to django-users@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/CAJxq848-fyg6KmLNx5ZwftrT66S%3DYpAUGTDY7%3D%3DJXkSJ3P7LbA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
