Closed GoogleCodeExporter closed 8 years ago
brodie,
While I agree that I should have a setup.py, "deployment" is current just: put
the
single file markdown2.py on your Python path. Your patch does not include a
setup.py
-- did you intend to provide one?
The Makefile.py that you refer to does not have "useless cruft". It has
functionality
that is useful to me. E.g.: This will 'hg pull' the pygments Python package for
testing the "code-color" feature of markdown2:
mk pygments
This will list the TODOs I've marked in the code:
mk todo
This will open the bug page:
mk bugs
Perhaps not useful to you, but that doesn't not make it cruft.
Removing the test runner in favour of nose presumes that I *use* nose and am
familiar
with it. I am aware of nose. I know that it has a lot of features my
'testlib.py'
does not, but I don't know that it has *all* the features I want. For example,
with
your patch can I do this to list available tests:
cd test
python test.py -l
Can I do this to run all tests associated with issue9:
python test.py issue9
Or to run all tests except those that I know currently fail:
python test.py -- -knownfailure
You give no reason why "dumping everning into one file is a little silly". I
find it
not silly because everything is conveniently in one file: which makes
deployment much
easier.
I would be happy to include a setup.py that you provide -- as I *would* like to
have
one and put markdown2.py on PyPI.
Original comment by tre...@gmail.com
on 29 Jan 2008 at 5:14
Sorry about that, I forgot to add the file to my working directory before
making the patch. It should have a
setup.py now.
I don't think the Makefile is really that useful; you could just make those
scripts on your own environment
that you don't bundle with the application. I can see how your test runner
might have special features you
don't get with other runners, but I think moving to something more standard
like nose would be a better idea
in the long run.
And I thought the comment about separating things out was kind of
self-explanatory. When you shove every
bit of code into one file and that file starts reaching thousands of lines,
well, it becomes hard to read and
navigate. Making it a package doesn't affect deployment at all if you're using
distutils or setup.py, but you will
have to make your own script runner for those who don't have setuptools
(scripts/markdown2 with
"#!python\n...").
Also note that removing that Makefile removes the dependencies on the "which"
library, and means needing
to bundle one less thing. And it's not essential to the operation of the
program either, so I don't see the
benefit of bundling it.
Original comment by brodie....@gmail.com
on 29 Jan 2008 at 2:03
Attachments:
Also, another thing I forgot to mention: You'll need to create a MANIFEST.in
file that lists what non-source code
files you want to include. Ideally you should have everything specified so that
generating a source tarball with
setup.py creates the same directories and files as what you started with.
Original comment by brodie....@gmail.com
on 31 Jan 2008 at 8:04
This is in pypi now (as of a long while ago).
Original comment by tre...@gmail.com
on 27 Apr 2012 at 7:18
Original issue reported on code.google.com by
brodie....@gmail.com
on 28 Jan 2008 at 4:12Attachments: