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
Hello,
I developed some moderate-sized python scripts that I would like to distribute
as python modules. I have never shipped modules before and I read
http://docs.python.org/distutils/index.html. I was able to generate a source
distribution, but I still have some questions.
1) My module conta
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
hip this
> to a customer? Can I create .pyc files so
> that the customer does not have to install the argparse
> module?
>
> If not, and I want to go back into the 2.3+ range,
> should I just use optparse?
>
> I guess what I am asking here is are there any
> guidelines/rec
o the 2.3+ range,
should I just use optparse?
I guess what I am asking here is are there any
guidelines/recommendations for shipping python
programs to customers?
Thanks in advance,
Kris
--
Mr. Kristen J. Webb
Teradactyl LLC.
PHONE: 1-505-242-1091
EMAIL: kw...@teradactyl.com
VISIT:
12 matches
Mail list logo
