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


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

the general development using Python

Started byajetrumpet@gmail.com
First post2013-07-08 18:45 -0700
Last post2013-07-09 19:25 -0400
Articles 4 on this page of 24 — 8 participants

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 2 of 2 — ← Prev page 1 [2]


#50401

FromJoshua Landau <joshua@landau.ws>
Date2013-07-11 00:57 +0100
Message-ID<mailman.4556.1373500673.3114.python-list@python.org>
In reply to#50397
On 11 July 2013 00:18, CM <cmpython@gmail.com> wrote:
>
>> 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.)

Yeah, but why keep shipping the Python interpreter? If you choose the
installer route, you don't have to keep shipping it -- it's only
downloaded if you need it. If not, then you don't download it again.

> 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.

The problem is that it hides it all inside the .exe file. And I'm not
suggesting putting Python inside the archive -- just the runtime
dependencies.

>> There are a lot of ways of making an installer <blah blah blah>.
>> 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.

Fair enough.

> 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?

But I still think my way is better. Perhaps I'm just too pragmatic
about these things. This was triggered by the OP's original request --
he sounds very much like he doesn't actually want this -- and it seems
to have stuck. I don't know if being pragmatic is a bad thing, though.

In the end, something like this is best solved with a bit of A/B
testing¹. Sit a couple of your audience down, give them the best
implementation of each strategy (starting from the website) for some
trivialised module and see what they think. If it turns out that being
pragmatic does have compromises, I'm not going to argue with the data.
I'd still be grumpy, though.

¹ This of course assumes you care enough to do so.

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


#50472

FromCM <cmpython@gmail.com>
Date2013-07-11 11:37 -0700
Message-ID<3d01aba0-99b8-4b95-8350-173e436cb6e2@googlegroups.com>
In reply to#50401
On Wednesday, July 10, 2013 7:57:11 PM UTC-4, Joshua Landau wrote:

> Yeah, but why keep shipping the Python interpreter? If you choose the 
> installer route, you don't have to keep shipping it -- it's only
> downloaded if you need it. If not, then you don't download it again.

I admit that not necessarily shipping the Python interpreter is much more efficient if your client base is expected to be a lot of people who already have Python and a lot of the common libraries (like wxPython).  I have a fair number of Python 3rd party libraries already on my computer, so for me, it is preferable to just download the .py files the developer has made.  

For some of the things I have thought about doing, though, the majority of the clients would never even have heard of Python other than Monty or the constrictor.  



> But I still think my way is better. Perhaps I'm just too pragmatic 
> about these things. This was triggered by the OP's original request --
> he sounds very much like he doesn't actually want this -- and it seems
> to have stuck. I don't know if being pragmatic is a bad thing, though.

I'll definitely think about the business angle of doing it the way you suggest.  For example, for consulting work where the end user is a technical worker who just need a script to automate some processes, and you expect to be providing a number of scripts over time in this way, a good way to install and setup a Python + GUI toolkit + other likely necessary libraries would be great.  For more "product sales to the mass populous", I'm less sure.
 
> In the end, something like this is best solved with a bit of A/B
> testing¹. Sit a couple of your audience down, give them the best
> implementation of each strategy (starting from the website) for some
> trivialised module and see what they think. If it turns out that being
> pragmatic does have compromises, I'm not going to argue with the data.
> I'd still be grumpy, though.

Makes sense.  I'm dubious about the full validity of A/B testing data without large data sets, but yes, at least one would be getting a feel for it.  I can also see what other projects/businesses are doing.

Thanks for the input!

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


#50394

FromIan Kelly <ian.g.kelly@gmail.com>
Date2013-07-10 16:10 -0600
Message-ID<mailman.4552.1373494254.3114.python-list@python.org>
In reply to#50296
On Tue, Jul 9, 2013 at 10:49 PM, CM <cmpython@gmail.com> wrote:
> 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.

It should be noted that PyInstaller is confusingly named.  It actually
creates standalone executables, not installers.

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


#50282

FromDennis Lee Bieber <wlfraed@ix.netcom.com>
Date2013-07-09 19:25 -0400
Message-ID<mailman.4479.1373412314.3114.python-list@python.org>
In reply to#50187
On Mon, 8 Jul 2013 18:45:16 -0700 (PDT), ajetrumpet@gmail.com declaimed the
following:

>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).
>
	Well, the first thing is to realize that ALL the common "one-file"
solutions are faking it -- they zip up a Python interpreter and all
libraries, along with the application files. When "run" they unpack all of
that into a temporary location, run, and then delete the temporary copy of
the files (and since Python, as I recall, can now load modules from a ZIP
file, they may not even fully unpack the mess).

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [standalone]


Page 2 of 2 — ← Prev page 1 [2]

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


csiph-web