I should also mention that these are just my personal best practices that I've
put together during my time working with/on OS projects. You'll almost never
find two projects with identical packaging, so really at the end of the day,
it's totally up to you and your particular project requirements
1) IMHO, these should be two distinct steps. You will definitely want to run
unit tests without sdist and likewise, I'm sure you'll want to sdist without
unit tests. Personally, if I wanted to combine the two, I'd create tasks in a
makefile and just run something along the lines of: make unit sd
On 10/12/11 3:26 PM, Chris Angelico wrote:
On Thu, Oct 13, 2011 at 8:10 AM, Kristen J. Webb wrote:
My main motivation to use .pyc is to keep end users from changing scripts,
breaking things, and then calling us. Tamper proofing may be an
alternative approach if anyone has suggestions.
I w
On 10/12/11 6:02 PM, Andrea Crotti wrote:
Why do you want to use the system python and system libraries?
It is a standard, just like glibc on linux, I'd like my code should work
on the OS with minimal intrusion.
If you want to avoid too much troubles and compatibility hell maybe
give PyInst
In article ,
Andrea Crotti wrote:
> And also the world is a funny place, but does it really happen that
> a customer changes the code in your python scripts, and the *complain*
> if it doens't work anymore??
You sound like somebody who has never had to support paying customers :-)
--
http://ma
On 10/12/2011 10:10 PM, Kristen J. Webb wrote:
I tried experimenting with .pyc files only to end up at:
RuntimeError: Bad magic number in .pyc file
can't run 2.5 pyc files on 2.6 :(
My main motivation to use .pyc is to keep end users from changing
scripts,
breaking things, and then calling u
On Thu, Oct 13, 2011 at 8:10 AM, Kristen J. Webb wrote:
> My main motivation to use .pyc is to keep end users from changing scripts,
> breaking things, and then calling us. Tamper proofing may be an
> alternative approach if anyone has suggestions.
>
I wouldn't bother; if you're worried about th
I tried experimenting with .pyc files only to end up at:
RuntimeError: Bad magic number in .pyc file
can't run 2.5 pyc files on 2.6 :(
My main motivation to use .pyc is to keep end users from changing scripts,
breaking things, and then calling us. Tamper proofing may be an
alternative approach
On Tue, 11 Oct 2011 17:04:45 -0600, Kristen J. Webb wrote:
> After some more digging I see that I can easy_install argparse on my
> development system.
>
> My question is will I be able to ship this to a customer? Can I create
> .pyc files so that the customer does not have to install the argpar
On Tue, Oct 11, 2011 at 05:04:45PM -0600, Kristen J. Webb wrote:
> I am new to python coming from the C/shell side.
> We have been experimenting with some code
> samples and now I'm looking at some command line
> argument processing. I find
>
> getopt older
> optparse new in 2.3
> argparse new in
10 matches
Mail list logo
