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

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

the general development using Python

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

Contents

  the general development using Python ajetrumpet@gmail.com - 2013-07-08 18:45 -0700
    Re: the general development using Python Joshua Landau <joshua.landau.ws@gmail.com> - 2013-07-09 02:59 +0100
    Re: the general development using Python Chris Angelico <rosuav@gmail.com> - 2013-07-09 13:07 +1000
    Re: the general development using Python Joel Goldstick <joel.goldstick@gmail.com> - 2013-07-08 22:13 -0400
    Re: the general development using Python CM <cmpython@gmail.com> - 2013-07-08 21:46 -0700
      Re: the general development using Python Chris Angelico <rosuav@gmail.com> - 2013-07-09 15:03 +1000
        Re: the general development using Python CM <cmpython@gmail.com> - 2013-07-09 16:29 -0700
      Re: the general development using Python Ian Kelly <ian.g.kelly@gmail.com> - 2013-07-09 02:41 -0600
      Re: the general development using Python Chris Angelico <rosuav@gmail.com> - 2013-07-09 23:59 +1000
      Re: the general development using Python Joshua Landau <joshua.landau.ws@gmail.com> - 2013-07-09 22:21 +0100
        Re: the general development using Python CM <cmpython@gmail.com> - 2013-07-09 16:38 -0700
    Re: the general development using Python Joshua Landau <joshua.landau.ws@gmail.com> - 2013-07-09 22:13 +0100
      Re: the general development using Python CM <cmpython@gmail.com> - 2013-07-09 16:35 -0700
        Re: the general development using Python Joshua Landau <joshua@landau.ws> - 2013-07-10 01:14 +0100
          Re: the general development using Python CM <cmpython@gmail.com> - 2013-07-09 19:16 -0700
            Re: the general development using Python Chris Angelico <rosuav@gmail.com> - 2013-07-10 12:53 +1000
            Re: the general development using Python Joshua Landau <joshua@landau.ws> - 2013-07-10 05:12 +0100
              Re: the general development using Python CM <cmpython@gmail.com> - 2013-07-09 21:49 -0700
                Re: the general development using Python Joshua Landau <joshua@landau.ws> - 2013-07-10 06:49 +0100
                  Re: the general development using Python CM <cmpython@gmail.com> - 2013-07-10 16:18 -0700
                    Re: the general development using Python Joshua Landau <joshua@landau.ws> - 2013-07-11 00:57 +0100
                      Re: the general development using Python CM <cmpython@gmail.com> - 2013-07-11 11:37 -0700
                Re: the general development using Python Ian Kelly <ian.g.kelly@gmail.com> - 2013-07-10 16:10 -0600
    Re: the general development using Python Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-07-09 19:25 -0400

Page 1 of 2  [1] 2  Next page →

#50187 — the general development using Python

all,

I am unhappy with the general Python documentation and tutorials.  I have worked with Python very little and I'm well aware of the fact that it is a lower-level language that integrates with the shell.

I came from a VB legacy background and I've already "un-learned" everything that I need to (I know, that language stinks, and isn't OOP or even useful!).

I have to get back into writing Python but I'm lacking one thing ... a general understanding of how to write applications that can be deployed (either in .exe format or in other formats).

So my issue is basically to understand how to go about writing programs and compiling them so they can be deployed to less tech-savvy people.  Here's what I think I have to do, in a general sense:

=> Pick a GUI and just run through the tutorials to learn the interfaces as fast as possible.

This is all fine and dandy, but more than likely when I do this the people that I am sending solutions to will, if not receiving a simple .exe file, receive the package from me and say to themselves "what in the world do I do with this!?"

Is there anyway you guys would suggest that I fix this or help them deal with complex languages like Python and programs written with it?

thanks guys.

[toc] | [next] | [standalone]

#50188

On 9 July 2013 02:45,  <ajetrumpet@gmail.com> wrote:
> all,
>
> I am unhappy with the general Python documentation and tutorials.  I have worked with Python very little and I'm well aware of the fact that it is a lower-level language that integrates with the shell.
>
> I came from a VB legacy background and I've already "un-learned" everything that I need to (I know, that language stinks, and isn't OOP or even useful!).
>
> I have to get back into writing Python but I'm lacking one thing ... a general understanding of how to write applications that can be deployed (either in .exe format or in other formats).
>
> So my issue is basically to understand how to go about writing programs and compiling them so they can be deployed to less tech-savvy people.  Here's what I think I have to do, in a general sense:
>
> => Pick a GUI and just run through the tutorials to learn the interfaces as fast as possible.
>
> This is all fine and dandy, but more than likely when I do this the people that I am sending solutions to will, if not receiving a simple .exe file, receive the package from me and say to themselves "what in the world do I do with this!?"
>
> Is there anyway you guys would suggest that I fix this or help them deal with complex languages like Python and programs written with it?

You cannot compile Python in any meaningful way that does what you want.

There are projects that "bundle" the CPython interpreter with your
project, but this makes those files really big. I suggest just making
sure that Python is installed on their end - it's a one-time thing
anyway.

You don't expect to be able to run Javascript without a Javascript
interpreter (such as a browser) so why would you expect differently
for Python?

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

#50189

On Tue, Jul 9, 2013 at 11:45 AM,  <ajetrumpet@gmail.com> wrote:
> I have to get back into writing Python but I'm lacking one thing ... a general understanding of how to write applications that can be deployed (either in .exe format or in other formats).

That's one last thing you need to un-learn, then :)

You distribute Python applications simply as they are - as a .py file
(or a collection of .py files), and your users run them. It's really
that simple!

In fact, deploying to .exe or equivalent would restrict your users to
those running a compatible OS (same OS, same word/pointer size (32-bit
or 64-bit), possibly other restrictions too), whereas deploying the
.py files just requires that they have a compatible Python interpreter
installed. Target the three most popular desktop platforms all at
once, no Linux/Windows/Mac OS versioning. Target the lesser-known
platforms like OS/2 with the same script. And completely eliminate the
"compile step", which might take a long time with large projects.
(Okay, your code does still get compiled, but the interpreter manages
all that for you. All you need to know is that the .pyc files don't
need to be distributed.)

Python - like most other modern high level languages - is designed to
save you the hassle of working with the details. This is another of
those hassle-savings. :)

ChrisA

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

#50190

[Multipart message — attachments visible in raw view] — view raw

On Mon, Jul 8, 2013 at 9:45 PM, <ajetrumpet@gmail.com> wrote:

> all,
>
> I am unhappy with the general Python documentation and tutorials.  I have
> worked with Python very little and I'm well aware of the fact that it is a
> lower-level language that integrates with the shell.
>
> I came from a VB legacy background and I've already "un-learned"
> everything that I need to (I know, that language stinks, and isn't OOP or
> even useful!).
>
> I have to get back into writing Python but I'm lacking one thing ... a
> general understanding of how to write applications that can be deployed
> (either in .exe format or in other formats).
>
> So my issue is basically to understand how to go about writing programs
> and compiling them so they can be deployed to less tech-savvy people.
>  Here's what I think I have to do, in a general sense:
>
> => Pick a GUI and just run through the tutorials to learn the interfaces
> as fast as possible.
>
> This is all fine and dandy, but more than likely when I do this the people
> that I am sending solutions to will, if not receiving a simple .exe file,
> receive the package from me and say to themselves "what in the world do I
> do with this!?"
>
> Is there anyway you guys would suggest that I fix this or help them deal
> with complex languages like Python and programs written with it?
>
> thanks guys.
> --
> http://mail.python.org/mailman/listinfo/python-list
>

Why do you want to use python?  It isn't a language that can be packaged as
an executable.  Who are these people who you make software for who need to
have a single file?

-- 
Joel Goldstick
http://joelgoldstick.com

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

#50192

On Monday, July 8, 2013 9:45:16 PM UTC-4, ajetr...@gmail.com wrote:
> all,
> 
> 
> 
> I am unhappy with the general Python documentation and tutorials.  

OK.  Do you mean the official Python.org docs?  Which tutorials?  There's a ton out there.

> I have worked with Python very little and I'm well aware of the fact that it is a lower-level language that integrates with the shell.

I thought it was a high level language. Integrates with the shell?  Isn't it just simplest to think of it as a programming language and that's what you need to know?


> I came from a VB legacy background and I've already "un-learned" everything that I need to (I know, that language stinks, and isn't OOP or even useful!).

On that last point, I think a quick Google search of job postings suggests otherwise.

> I have to get back into writing Python but I'm lacking one thing ... 

I'm guessing it is probably more than *one* thing.  But moving along...

> So my issue is basically to understand how to go about writing programs and compiling them so they can be deployed to less tech-savvy people.  Here's what I think I have to do, in a general sense:
> 
> => Pick a GUI and just run through the tutorials to learn the interfaces as fast as possible.

Yes.

> This is all fine and dandy, but more than likely when I do this the people 
> that I am sending solutions to will, if not receiving a simple .exe file, 
> receive the package from me and say to themselves "what in the world do I do 
> with this!?"

Yes. If they are not Python users, that's right.  
 
> Is there anyway you guys would suggest that I fix this or help them deal with 
> complex languages like Python and programs written with it?

Again, "complex language"?  It's a programming language, that's it.

Anyway, yes: read the first sentence after "Overview" here:
https://us.pycon.org/2012/schedule/presentation/393/

The other respondents to your post have a good philosophical point, that it is kind of unfortunate to bundle up a Python program and the whole interpreter when you can just send a much smaller .py file, but in reality, there are a number of cases where doing it is preferred.  First, your case with completely unPython-savvy users.  Second, if you have a lot of dependencies and it would make it necessary for end users to install all of them for your program to work.  

In the end, I'm a fan of them.  Couple of responses to others in that regard:

> There are projects that "bundle" the CPython interpreter with your
> project, but this makes those files really big.

Maybe 5-20 MB.  That's a lot bigger than a few hundred K, but it's not that important to keep size down, really.

>  Target the three most popular desktop platforms all at once, no 
> Linux/Windows/Mac OS versioning. 

Ehhh... There are differences, in, e.g., wxPython between the three platforms, and you can either do different versions or, more aptly, just fix these differences in your code with conditional statements ("if this is Win, do this, else do that").

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

#50200

On Tue, Jul 9, 2013 at 2:46 PM, CM <cmpython@gmail.com> wrote:
>>  Target the three most popular desktop platforms all at once, no
>> Linux/Windows/Mac OS versioning.
>
> Ehhh... There are differences, in, e.g., wxPython between the three platforms, and you can either do different versions or, more aptly, just fix these differences in your code with conditional statements ("if this is Win, do this, else do that").

Please watch your citations, you quoted several different people
without any hint as to who said what :)

Yes, there are a few differences. But a *lot* less than there are
differences between a Linux executable and a Windows one, or between
32-bit and 64-bit binaries, or between Red Hat and Debian packages,
etc, etc, etc. Differences in windowing systems or newlines or path
separators will need to be dealt with regardless of the app, but there
are a whole pile of additional differences when you distribute binary
executables.

ChrisA

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

#50283

On Tuesday, July 9, 2013 1:03:14 AM UTC-4, Chris Angelico wrote:
> On Tue, Jul 9, 2013 at 2:46 PM, CM <cmpython@gmail.com> wrote:
> 
> >>  Target the three most popular desktop platforms all at once, no
> 
> >> Linux/Windows/Mac OS versioning.
> 
> > Ehhh... There are differences, in, e.g., wxPython between the three platforms, and you can either do different versions or, more aptly, just fix these differences in your code with conditional statements ("if this is Win, do this, else do that").
> 
> 
> 
> Please watch your citations, you quoted several different people
> without any hint as to who said what :)

Uhp, sorry.  I was just trimming for space, but good point.  

> Yes, there are a few differences. But a *lot* less than there are 
> differences between a Linux executable and a Windows one, or between
> 32-bit and 64-bit binaries, or between Red Hat and Debian packages,
> etc, etc, etc. Differences in windowing systems or newlines or pat
> separators will need to be dealt with regardless of the app, but there
> are a whole pile of additional differences when you distribute binary
> executables.

Agreed.  That said, some of whether it is worth the trouble will depend on whether the OP (or whoever) is planning to deploy for all these platforms.  If it is just the big three, then it will be some (significant) work at first to get the executables made, but then, with some luck, less work to maintain the various platform versions.  

But sure, I am not at all disputing the idea that if you have, say, a Python program with wxPython, and the user is easily willing to install (or already has) Python and wxPython, to just send the .py file.  It would be ludicrous to not do that.

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

#50227

On Mon, Jul 8, 2013 at 10:46 PM, CM <cmpython@gmail.com> wrote:
>> There are projects that "bundle" the CPython interpreter with your
>> project, but this makes those files really big.
>
> Maybe 5-20 MB.  That's a lot bigger than a few hundred K, but it's not that important to keep size down, really.

Funny story: at my workplace we solve the distribution problem by
placing both the Python interpreter and applications on a network
share.  I have inherited a program that nonetheless is stored on the
network share as a pyInstaller bundle because it is (perceived to be)
faster to transfer a single .exe over the network during start-up than
all the individual files on demand.

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

#50245

On Tue, Jul 9, 2013 at 6:41 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Mon, Jul 8, 2013 at 10:46 PM, CM <cmpython@gmail.com> wrote:
>>> There are projects that "bundle" the CPython interpreter with your
>>> project, but this makes those files really big.
>>
>> Maybe 5-20 MB.  That's a lot bigger than a few hundred K, but it's not that important to keep size down, really.
>
> Funny story: at my workplace we solve the distribution problem by
> placing both the Python interpreter and applications on a network
> share.  I have inherited a program that nonetheless is stored on the
> network share as a pyInstaller bundle because it is (perceived to be)
> faster to transfer a single .exe over the network during start-up than
> all the individual files on demand.

It might actually be faster, if the startup cost of a transfer is high
- which it very often can be. But it would likely also be faster to
transfer a single .zip or .tar.gz for the same benefit; or, depending
on requirements, use 'git pull' or scp.

ChrisA

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

#50276

On 9 July 2013 05:46, CM <cmpython@gmail.com> wrote:
*I said*:
>> There are projects that "bundle" the CPython interpreter with your
>> project, but this makes those files really big.
>
> Maybe 5-20 MB.  That's a lot bigger than a few hundred K, but it's not that important to keep size down, really.

Fair enough. It's not something I'd EMail to a friend, though.

*Chris Angelico said*:
>>  Target the three most popular desktop platforms all at once, no
>> Linux/Windows/Mac OS versioning.
>
> Ehhh... There are differences, in, e.g., wxPython between the three platforms, and you can either do different versions or, more aptly, just fix these differences in your code with conditional statements ("if this is Win, do this, else do that").

I agree with Chris -- it doesn't take much to make a package
(depending on what you're doing) work on both Windows and Linux. It
takes a hell of a lot to make a .exe file work on both.

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

#50286

On Tuesday, July 9, 2013 5:21:22 PM UTC-4, Joshua Landau wrote:
> On 9 July 2013 05:46, CM <cmpython@gmail.com> wrote:
 
> > Maybe 5-20 MB.  That's a lot bigger than a few hundred K, but it's not that important to keep size down, really.
 
> Fair enough. It's not something I'd EMail to a friend, though.

Again, agreed.  I can't even try to email that; Gmail won't let me.  I've had to use Dropbox to transfer files to a client.  At this point, I probably *should* have had them install Python and wxPython, but then again, I suspected that operation could have (somehow) gone awkwardly, and I know that packaging up my program for each new version takes about five minutes and one click of a button, then drag the .exe to Dropbox, so maybe not.

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

#50274

On 9 July 2013 03:08, Adam Evanovich <ajetrumpet@gmail.com> wrote:
> Joshua,
>
> Why did you send me an email reply instead of replying in the google groups?

Apologies, although it's not quite that simple. I access this list the
way it was originally intended -- through EMail. I replied "to all",
which default to both the list (by CC) and the person, and I forgot to
drop you from the reply.

If you use Google Groups, it's also best to read
http://wiki.python.org/moin/GoogleGroupsPython first.

Secondly, please don't top post.

It seems reasonable to post back this to the list, so I have.

> I just want to make sure that it really is as simple as:
>
> 1) Installing Python on users machine.
> 2) Running the deployment on their end to parse the DOM via the
> application/tool that I write.
> 3) Waiting for the output so they can see it.
>
> Is it really any more complicated than that (other than writing the
> tool/app, obviously)?

As other's have responded, that's it.

> Can you tell me quickly what kind of deployment
> options Python has?

What you can just do is send a .zip/.tar.gz/.tar.xz or other archive
format with all of the files they need to have. Normally I find it
nicest to just run like that (I personally reserve installing for the
things that benefit from it).

If you want installation as an option, then AFAIK the only option in
wide usage is http://docs.python.org/3/distutils/index.html. There may
be others, but you'd need to ask the experts about that.

> Can you wrap source code/libs/apps into an EXE and just
> send that to the end user?  Or is it more complicated for them?

Urm.. yes. But don't. That's the "nuclear" option and isn't a good
one. If you have a *really genuinely good reason* (you probably don't)
to do this, there are ways.

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

#50285

On Tuesday, July 9, 2013 5:13:17 PM UTC-4, Joshua Landau wrote:
> On 9 July 2013 03:08, Adam Evanovich <ajetrumpet@gmail.com> wrote:
> > Can you wrap source code/libs/apps into an EXE and just 
> > send that to the end user?  Or is it more complicated for them?
> 

> Urm.. yes. But don't. That's the "nuclear" option and isn't a good 
> one. If you have a *really genuinely good reason* (you probably don't)
> to do this, there are ways.

I still think you are overstating it somewhat.  Have a website on which you distribute your software to end users (and maybe even--gasp--charge them for it)?  *That's* a good reason.  And that's one of the top ways that users get software.  Also, many programs rely on 2-3 dependencies, and sometimes that is asking a lot of the end user to install.  (I know, I know, it shouldn't be...and with things like pip it really shouldn't be, but you know how it goes).  

I completely agree with you in Ideal World thinking, but in the gnarly one we actually have, .exe files *often* have their place.

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

#50288

On 10 July 2013 00:35, CM <cmpython@gmail.com> wrote:
> On Tuesday, July 9, 2013 5:13:17 PM UTC-4, Joshua Landau wrote:
>> On 9 July 2013 03:08, Adam Evanovich <ajetrumpet@gmail.com> wrote:
>> > Can you wrap source code/libs/apps into an EXE and just
>> > send that to the end user?  Or is it more complicated for them?
>
>> Urm.. yes. But don't. That's the "nuclear" option and isn't a good
>> one. If you have a *really genuinely good reason* (you probably don't)
>> to do this, there are ways.
>
> I still think you are overstating it somewhat.  Have a website on which you distribute your software to end users (and maybe even--gasp--charge them for it)?  *That's* a good reason.

Not really. It'd be a good reason if it disqualifies the other
options, but it doesn't. Just give them an archive.

If you're worried about keeping your code "safe" then:

1) You're going about it the wrong way. Like, seriously wrongly.
2) It's not going to be totally secure even if you do it the right way.

The most safeyest way you can do with Python AFAIK¹² is a long winded
process to basically just "compile it with Cython". Note that it still
requires CPython (the normal python interpreter) to be installed --
you get lots of .so files instead of a .exe. There are other silly
things you can do as well.

> And that's one of the top ways that users get software.

Pah, I much prefer it over here on Linux :P.

> Also, many programs rely on 2-3 dependencies, and sometimes that is asking a lot of the end user to install.  (I know, I know, it shouldn't be...and with things like pip it really shouldn't be, but you know how it goes).

But why do they need to install it at all? If you're not installing
the .py file, then just include those dependencies in the archive --
.py files are tiny. If you are installing the .py with a setup.py
(like with the link I included), then just install them at the same
time.

> I completely agree with you in Ideal World thinking, but in the gnarly one we actually have, .exe files *often* have their place.

Yeah, but not for Python :P. For Python .exe files are a rarity and
should be kept that way.

¹ I'm not even sure that Cython doesn't keep a copy of the original
code for crash reports and other debugging stuff...
² Theres also Nuitka, which I found right now, so I'm not sure if it's
any good for this or not. I haven't tried, really.

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

#50291

On Tuesday, July 9, 2013 8:14:44 PM UTC-4, Joshua Landau wrote:
> > I still think you are overstating it somewhat.  Have a website on which you distribute your software to end users (and maybe even--gasp--charge them for it)?  *That's* a good reason.
 
> Not really. It'd be a good reason if it disqualifies the other 
> options, but it doesn't. Just give them an archive.

> If you're worried about keeping your code "safe" then:

That's not what I was thinking in terms of, although it's fine to note that since people on this list occasionally think just that.  What I was thinking of was that if you are going to sell software, you want to make it as easy as possible, and that includes not making the potential customer have to install anything, or even agree to allow you to "explicitly" install a runtime on their computer.  If the potential customer just sees, clicks, and installs, that should be the most they ought to have to do.

> > Also, many programs rely on 2-3 dependencies, and sometimes that is asking a lot of the end user to install.  (I know, I know, it shouldn't be...and with things like pip it really shouldn't be, but you know how it goes).
> 
> 
> But why do they need to install it at all? If you're not installing 
> the .py file, then just include those dependencies in the archive -- 
> .py files are tiny. If you are installing the .py with a setup.py
> (like with the link I included), then just install them at the same
> time.

Maybe.  I'll have to think about it.  I'm referring to libaries as dependencies. So for example, though .py files are small, wxPython, for example, isn't tiny, nor are other libraries one might use.

> Yeah, but not for Python :P. For Python .exe files are a rarity and
> should be kept that way.

That there is a significant interest in creating exe files suggest that not everyone feels that way.

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

#50293

On Wed, Jul 10, 2013 at 12:16 PM, CM <cmpython@gmail.com> wrote:
> On Tuesday, July 9, 2013 8:14:44 PM UTC-4, Joshua Landau wrote:
>> Yeah, but not for Python :P. For Python .exe files are a rarity and
>> should be kept that way.
>
> That there is a significant interest in creating exe files suggest that not everyone feels that way.

No; there can be interest in something that should be a rarity. I have
interest in turning a MUD client around backwards and having it bind
and listen instead of connecting, but I know that that should be
extremely rare. Useful, but rare.

There are a number of wrong reasons for wanting to turn Python scripts
into exe files, and a number of better reasons that place different
demands on the structure. For instance, some people aren't trying to
conceal their code, just to make a simple deployment system (as per
this thread). In that case, some form of self-extracting zip file
might be best. Others try to prevent their code from being stolen, or
tampered with. That's approximately impossible, but in any case, that
will obviously NOT be just a sfx. And then there are those who want to
compile to binary for speed (and not all of them are even correct in
what they're looking for). So there'll always be multiple solutions to
what you think is one problem ("create an exe file from a Python
application"), suggesting that it might not be one problem at all.

ChrisA

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

#50295

On <some multitude of times>, CM <cmpython@gmail.com> wrote:
> What I was thinking of was that if you are going to sell software, you want to make it as easy as possible, and that includes not making the potential customer have to install anything, or even agree to allow you to "explicitly" install a runtime on their computer.  If the potential customer just sees, clicks, and installs, that should be the most they ought to have to do.

I don't really get what you are saying. Do you, or do you not, want it
installed?

> Also, many programs rely on 2-3 dependencies, and sometimes that is asking a lot of the end user to install.  (I know, I know, it shouldn't be...and with things like pip it really shouldn't be, but you know how it goes).
>
>> I responded (to some parts):
>> But why do they need to install it at all? If you're not installing
>> the .py file, then just include those dependencies in the archive --
>> .py files are tiny. If you are installing the .py with a setup.py
>> (like with the link I included), then just install them at the same
>> time.
>
> Maybe.  I'll have to think about it.  I'm referring to libaries as dependencies. So for example, though .py files are small, wxPython, for example, isn't tiny, nor are other libraries one might use.

Please excuse the fact I haven't done anything serious on Windows in
years so I'm not really sure what I'm saying. How does Windows deal
with dependencies?

It's going to have to be fetched at one point anyway, so that's either
at download-time, install-time or run-time. The first lets you just
add it to the archive, the second lets you deal with it through a good
standard distribution manager thing, the third is potentially crazy.
Hence, wutz za probem bruv?

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

#50296

On Wednesday, July 10, 2013 12:12:16 AM UTC-4, Joshua Landau wrote:
> On <some multitude of times>, CM <cmpython@gmail.com> wrote:
> 
> > What I was thinking of was that if you are going to sell software, you want to make it as easy as possible, and that includes not making the potential customer have to install anything, or even agree to allow you to "explicitly" install a runtime on their computer.  If the potential customer just sees, clicks, and installs, that should be the most they ought to have to do.

> I don't really get what you are saying. Do you, or do you not, want it 
> installed?

I'm just saying that sometimes one goes to download new software and are met with a statement such as:

"Installing Eclipse is relatively easy, but does involve a few steps and software from at least two different sources. Eclipse is a Java-based application and, as such, requires a Java runtime environment (JRE) in order to run. ...Regardless of your operating system, you will need to install some Java virtual machine (JVM). You may either install a Java Runtime Environment (JRE), or a Java Development Kit (JDK), depending on what you want to do with Eclipse."

This is not always the type of thing you want your customers to encounter. 

Can all the installation of the runtimes be done with an installer that is itself an .exe, like with PyInstaller?  If so, that's probably fine.


> > Maybe.  I'll have to think about it.  I'm referring to libaries as dependencies. So for example, though .py files are small, wxPython, for example, isn't tiny, nor are other libraries one might use.
> 
> Please excuse the fact I haven't done anything serious on Windows in 
> years so I'm not really sure what I'm saying. How does Windows deal
> with dependencies?
> 
> It's going to have to be fetched at one point anyway, so that's either
> at download-time, install-time or run-time. The first lets you just
> add it to the archive, the second lets you deal with it through a good
> standard distribution manager thing, the third is potentially crazy.
> Hence, wutz za probem bruv?

I'm good with the first way, and I'm fine with Linux's package manager/whatever doing it the second.  

To simplify everything:  sales require massive simplicity for (some) end users.  You can get 1-2 clicks out of them before they drop dead as buyers.  Furthermore, and I haven't mentioned this yet, an .exe file on Windows has the look of authenticity, whereas a .py file (which is a text file, really) doesn't, which might also matter to customer perceptions.  This is all psychology.  The ease of deployment side is up for grabs, but yes, potentially a hassle for cross platform deployment.

I'm open to the idea of using an installer .exe to set up the user's computer with Python and all the libraries he needs to get going.  I just haven't done that so far.

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

#50298

On 10 July 2013 05:49, CM <cmpython@gmail.com> wrote:
> On Wednesday, July 10, 2013 12:12:16 AM UTC-4, Joshua Landau wrote:
>> On <some multitude of times>, CM <cmpython@gmail.com> wrote:
>>
>> > What I was thinking of was that if you are going to sell software, you want to make it as easy as possible, and that includes not making the potential customer have to install anything, or even agree to allow you to "explicitly" install a runtime on their computer.  If the potential customer just sees, clicks, and installs, that should be the most they ought to have to do.
>
>> I don't really get what you are saying. Do you, or do you not, want it
>> installed?
>
> I'm just saying that sometimes one goes to download new software and are met with a statement such as:
>
> "Installing Eclipse is relatively easy, but does involve a few steps and software from at least two different sources. Eclipse is a Java-based application and, as such, requires a Java runtime environment (JRE) in order to run. ...Regardless of your operating system, you will need to install some Java virtual machine (JVM). You may either install a Java Runtime Environment (JRE), or a Java Development Kit (JDK), depending on what you want to do with Eclipse."
>
> This is not always the type of thing you want your customers to encounter.
>
> Can all the installation of the runtimes be done with an installer that is itself an .exe, like with PyInstaller?  If so, that's probably fine.

I don't get what PyInstaller has to do with that, it seems to do
something other than what you said. The rest of my naïve
just-thought-of-it-now approach is below.

>> > Maybe.  I'll have to think about it.  I'm referring to libaries as dependencies. So for example, though .py files are small, wxPython, for example, isn't tiny, nor are other libraries one might use.
>>
>> Please excuse the fact I haven't done anything serious on Windows in
>> years so I'm not really sure what I'm saying. How does Windows deal
>> with dependencies?
>>
>> It's going to have to be fetched at one point anyway, so that's either
>> at download-time, install-time or run-time. The first lets you just
>> add it to the archive, the second lets you deal with it through a good
>> standard distribution manager thing, the third is potentially crazy.
>> Hence, wutz za probem bruv?
>
> I'm good with the first way, and I'm fine with Linux's package manager/whatever doing it the second.

For the second I meant something like setuptools, distribute, distutils and co.

> To simplify everything:  sales require massive simplicity for (some) end users.  You can get 1-2 clicks out of them before they drop dead as buyers.

I was mainly talking in the context of the original post, where it
seems something slightly different was meant. If you're deploying to
customers, you'd want to offer them an installer. At least, I think
you would. That's different from packing Python into a .exe file and
pretending it's good-to-go.

If they don't want it installed, again the best thing to do is an
archive with some "executable" (possibly a batch file or something --
you Windows people would know better what you need) that just runs
"python main_file.py". Then get them to extract + click. That's 2
operations, and a lot faster than some silly install process.

That does require them to install Python, but you can just add
Python's installer in there. That makes 3 operations, but you can
always make the "launcher" run the installer if it's not found.

>Furthermore, and I haven't mentioned this yet, an .exe file on Windows has the look of authenticity, whereas a .py file (which is a text file, really) doesn't, which might also matter to customer perceptions.  This is all psychology.

Unfortunately I cannot argue with that stupidity. It's true but shameful.

> The ease of deployment side is up for grabs, but yes, potentially a hassle for cross platform deployment.
>
> I'm open to the idea of using an installer .exe to set up the user's computer with Python and all the libraries he needs to get going.  I just haven't done that so far.

There are a lot of ways of making an installer, and my current few
Googles have shown that distutils comes with a way of making .msi
files¹, and there's also http://wix.tramontana.co.hu/. Some random
internet guy reccomended https://code.google.com/p/omaha/, but I've no
idea if it's appropriate. There's also
http://nsis.sourceforge.net/Main_Page. Again, I'm no Windows user so
I'm talking by guessing.

These are saner solutions because they focus on installing rather than
pretending that a .exe file with a packaged Python is anything like a
compiled C source.

¹ Just run "python setup.py bdist_msi" with a working setup.py and you
get a free .msi! I don't know what the .msi assumes, and I have no way
of testing as of now.

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

#50397

> I was mainly talking in the context of the original post, where it 
> seems something slightly different was meant. If you're deploying to
> customers, you'd want to offer them an installer. At least, I think
> you would. That's different from packing Python into a .exe file and
> pretending it's good-to-go.

It depends.  In some sense, probably an .exe is the very simplest thing you can provide a user:  they download and move it to where they want, the click on it, it runs.   It *is* good-to-go, isn't it?  (btw, I know at least one person I've read on a forum who just won't use any installer--he feels it can put stuff on his computer where he doesn't have good easy control of it.)

Sometimes an installer might be preferable, especially if there are data or image files or tutorials or something that go with the .exe (that weren't, for some reason, bundled inside it).  

> If they don't want it installed, again the best thing to do is an
> archive with some "executable" (possibly a batch file or something --
> you Windows people would know better what you need) that just runs
> "python main_file.py". Then get them to extract + click. That's 2
> operations, and a lot faster than some silly install process.

But that's pretty much what the .exe that py2exe makes does anyway.  It just kind of hides it all inside the .exe file.

> There are a lot of ways of making an installer, and my current few 
> Googles have shown that distutils comes with a way of making .msi
> files¹, and there's also http://wix.tramontana.co.hu/. Some random
> internet guy reccomended https://code.google.com/p/omaha/, but I've no
> idea if it's appropriate. There's also
> http://nsis.sourceforge.net/Main_Page. Again, I'm no Windows user so
> I'm talking by guessing.

And InnoSetup, which I've used to good effect.

> These are saner solutions because they focus on installing rather than 
> pretending that a .exe file with a packaged Python is anything like a
> compiled C source.

I don't think most informed users of, say, py2exe think that.  I think they see it as "freezing" the application for single-file portability.  The fact that people will refer to it as "compiling it to an exe" is unfortunate, yes.

Again, for anyone selling software, just make as few steps as possible for the user.  Using py2exe (which is easy to do) to freeze a lot of .py scripts into one easily deployed app passes that test.  So does any simple method you mentioned, I'm sure.  It all gets us to the same place, right?

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web