Smileyt / python-markdown2

Automatically exported from code.google.com/p/python-markdown2
Other
0 stars 0 forks source link

Add setuptools and nose support #14

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
The current status of this project not being distutils or setuptools
compatible makes it very unattractive for me, and makes deploying a hassle.
The makefile provided has a lot of useless cruft.

I've attached a patch that adds a basic setup.py. It also removes the test
runner you made, replacing it with nose. There are also some fixes with
regards to how you detect for set() and reversed(), as well as some style
fixes.

I would also recommend you separate out the code into multiple modules.
Just dumping everything into one file is a little silly. I could see you at
least starting by separating out the command line runner and the parser
itself (e.g. markdown2.__init__ and markdown2.parser).

Once all this is done, I'd also add some more classifiers to setup.py and
submit it to PyPI.

Original issue reported on code.google.com by brodie....@gmail.com on 28 Jan 2008 at 4:12

Attachments:

GoogleCodeExporter commented 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

GoogleCodeExporter commented 8 years ago
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:

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
This is in pypi now (as of a long while ago).

Original comment by tre...@gmail.com on 27 Apr 2012 at 7:18