Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #73489 > unrolled thread

How to distribute python console program

Back to article view | Back to comp.lang.python

Contents

  How to distribute python console program Nicholas Cannon <nicholascannon1@gmail.com> - 2014-06-21 19:51 -0700
    Re: How to distribute python console program Jurko Gospodnetić <jurko.gospodnetic@pke.hr> - 2014-06-22 11:56 +0200
    Re: How to distribute python console program Nicholas Cole <nicholas.cole@gmail.com> - 2014-06-22 10:58 +0100
    Re: How to distribute python console program Terry Reedy <tjreedy@udel.edu> - 2014-06-22 14:25 -0400

#73489 — How to distribute python console program

I have a simple program that is ran in the console with 2 modules and i was wondering how i could like export it so i could give it to someone to use as like a utlitie in the console?

[toc] | [next] | [standalone]

#73492

   Hi Nicholas.

On 22.6.2014. 4:51, Nicholas Cannon wrote:
> I have a simple program that is ran in the console with
> 2 modules and i was wondering how i could like export it
> so i could give it to someone to use as like a utlitie
> in the console?

   Assumptions:
     * You have one script - script.py, using two additional module - 
module1.py & module2.py.
     * You want to hold the script in some generic Utility folder (on 
your system path or wherever). Let's refer to that folder as 
'D:\Utility', just to make it seem more realistic.
     * Target machine already has the desired Python environment installed.


   The simplest 'all in one' solution would be to simply copy script.py, 
module1.py & module2.py into the 'D:\Utility' folder. Then you can run 
script.py as a script (using whatever Python environment you prefer) and 
its folder (i.e. 'D:\Utility') will automatically be added to the Python 
path, ergo module1.py & module2.py can be easily imported using 'import 
module1' & 'import module2' respectively.

   One possible bad side to this organization is that the user does not 
necessarily know what module1.py & module2.py files are - they are 
stored together with other utility scripts but need not be runnable 
scripts by themselves. If they can be run as standalone scripts then 
that is all fine and well but if they are not - user does now know that 
they should not be and possibly what they are related to.


   A slight variation making it clear which scripts should be runnable 
directly and which should not would be to move module1.py & module.py 
under some 'D:\Utility\script_details' folder and add an empty 
__init__.py file to that folder as well.

   Then module1.py & module2.py can be imported as:
     'import script_details.module1'
   and:
     'import script_details.module2'
   respectively.


   Another addition is to prepare a packaged installer that installs your
files in one of the aforementioned structures as any other application, 
e.g. under '/usr/bin', 'C:\Program Files' or whatever, but that's 
strictly an addition to what was described earlier.


   If the script and the modules you mention are self-contained and are 
not intended to be reused elsewhere, then I don't think you need 
anything more complex than that. If they are not then you have an option 
to place the implementation module in some shared Python environment 
folder, e.g. a specific Python environment's 'site-packages' folder. 
That would allow you to easily reuse those modules from other scripts 
located in other folders, but it would also introduce additional 
complications - with it you need to make sure the folder you placed them 
on has indeed been configured to be located on the used Python 
environment's Python path.


   Another variation is to package an installer that basically installs 
a stand-alone Python distribution together with your script, e.g. like 
something done by cx_Freeze or similar projects. Then your target 
machine does not need to have Python installed separately, but on the 
other hand, the installation is much larger and you risk getting 
multiple Python installations all over the same machine. :-)


   Hope this helps.

   Best regards,
     Jurko Gospodnetić

[toc] | [prev] | [next] | [standalone]

#73493

On Sun, Jun 22, 2014 at 3:51 AM, Nicholas Cannon
<nicholascannon1@gmail.com> wrote:
> I have a simple program that is ran in the console with 2 modules and i was wondering how i could like export it so i could give it to someone to use as like a utlitie in the console?

I'm assuming that the 'someone' you want to give it to has python
installed (if they are running any kind of linux or OS X they should
do).

If so, you can use something like

https://pypi.python.org/pypi/ncdistribute/

to make single zip file that contains your code and all its
dependencies.  There is no need to unpack the zip file - python can
run it without unpacking, so you simply put the your_utility_name.pyz
file somewhere in the user's path and it can be run easily.  You can
even rename it so that it doesn't have the .pyz filename.

If you want to send your application to someone who doesn't have
python installed, things are trickier.

http://cx-freeze.sourceforge.net

aims to help you do that kind of thing.

Hope that helps,

Nicholas

[toc] | [prev] | [next] | [standalone]

#73502

On 6/22/2014 5:56 AM, Jurko Gospodnetić wrote:
>    Hi Nicholas.
>
> On 22.6.2014. 4:51, Nicholas Cannon wrote:
>> I have a simple program that is ran in the console with
>> 2 modules and i was wondering how i could like export it
>> so i could give it to someone to use as like a utlitie
>> in the console?

>    One possible bad side to this organization is that the user does not
> necessarily know what module1.py & module2.py files are - they are
> stored together with other utility scripts but need not be runnable
> scripts by themselves. If they can be run as standalone scripts then
> that is all fine and well but if they are not - user does now know that
> they should not be and possibly what they are related to.

The support modules could end with

if __name__ == '__main__':
   print("y.py is strictly a support module for x.py. When run "
         "by itself, it does not do anything except to print this."

However, I prefer the solution of bundling all into a zip.

-- 
Terry Jan Reedy

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web