Menu
▾
▴
python-markdown-discuss
|
From: kiorky <ki...@cr...> - 2009-10-04 15:18:22
Attachments:
signature.asc
markdown.patch
|
Hi Waylan, Some news from python24 packaging front ;). Attached patch make your Markdown package python-2.4 friendly. Feel free to merge/release it. The enjoying console output from the new dist and python 2.4: (test)kiorky@judith ~/projects/repos/python-markdown $ easy_install dist/Markdown-2.0.3.zip Processing Markdown-2.0.3.zip ... Installed /home/kiorky/projects/repos/python-markdown/test/lib/python2.4/site-packages/Markdown-2.0.3-py2.4.egg Processing dependencies for Markdown==2.0.3 Searching for elementtree ... Adding elementtree 1.2.7-20070827-preview to easy-install.pth file Installed ... Finished processing dependencies for Markdown==2.0.3 (test)kiorky@judith ~/projects/repos/python-markdown $ python -c "import markdown;print markdown.version" 2.0.3 cewing a écrit : > > kiorky wrote: >> I think the fix must be upstream and the author is quite responsive, >> just advertise him (i already did a bit earlier and im waiting for >> response). >> > As it turns out, we agree with your assessment completely. The problem lies > upstream and should properly be fixed there. There's quite a decent > analysis of the problem in > http://www.coactivate.org/projects/zopeskel-bbq-sprint/blog/2009/10/03/zopeskel-bbq-sprint-day-one/ > this blog post from the first day of the zopeskel spring (underway right > now). > > However, the installation of ZopeSkel 2.12 under python 2.4 was broken and > as it is used widely in the zope/plone world, leaving it in that state until > an upstream fix is made is not an option. We repaired the problem with > ZopeSkel by pinning a version of Cheetah that avoids the whole mess. This > will solve a truly bad problem for 99% of the folks who use ZopeSkel. > > It appears that you are in the remaining 1% for whom the solution has caused > another problem. Luckily, there are simple fixes available for you. You > can pin the version of Cheetah in your package to match that in ZopeSkel > (which is what you've done). Or you can remove the explicit dependency on > Cheetah and allow the dependency in ZopeSkel to install it for you. > > As > http://www.coactivate.org/projects/zopeskel-bbq-sprint/blog/2009/10/03/zopeskel-bbq-sprint-day-one/ > the blog post linked above states, we agree that the fix should be > upstream. We have plans to move on to making that fix next. If you have > the time, we'd welcome your help in getting Markdown repaired so that it can > be installed in python 2.4. As soon as that fix is made, we will unpin > ZopeSkel and everyone can go along their merry way. > > Thanks, > > c -- -- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF |
|
From: kiorky <ki...@cr...> - 2009-10-10 20:19:21
Attachments:
signature.asc
|
Hi waylan, Any Status ... !? kiorky a écrit : > Hi Waylan, > > Some news from python24 packaging front ;). > > Attached patch make your Markdown package python-2.4 friendly. > Feel free to merge/release it. > > The enjoying console output from the new dist and python 2.4: > > (test)kiorky@judith ~/projects/repos/python-markdown $ easy_install > dist/Markdown-2.0.3.zip > Processing Markdown-2.0.3.zip > ... > Installed > /home/kiorky/projects/repos/python-markdown/test/lib/python2.4/site-packages/Markdown-2.0.3-py2.4.egg > Processing dependencies for Markdown==2.0.3 > Searching for elementtree > ... > Adding elementtree 1.2.7-20070827-preview to easy-install.pth file > Installed > ... > Finished processing dependencies for Markdown==2.0.3 > > (test)kiorky@judith ~/projects/repos/python-markdown $ python -c "import > markdown;print markdown.version" > 2.0.3 > > > cewing a écrit : >> kiorky wrote: >>> I think the fix must be upstream and the author is quite responsive, >>> just advertise him (i already did a bit earlier and im waiting for >>> response). >>> >> As it turns out, we agree with your assessment completely. The problem lies >> upstream and should properly be fixed there. There's quite a decent >> analysis of the problem in >> http://www.coactivate.org/projects/zopeskel-bbq-sprint/blog/2009/10/03/zopeskel-bbq-sprint-day-one/ >> this blog post from the first day of the zopeskel spring (underway right >> now). >> >> However, the installation of ZopeSkel 2.12 under python 2.4 was broken and >> as it is used widely in the zope/plone world, leaving it in that state until >> an upstream fix is made is not an option. We repaired the problem with >> ZopeSkel by pinning a version of Cheetah that avoids the whole mess. This >> will solve a truly bad problem for 99% of the folks who use ZopeSkel. >> >> It appears that you are in the remaining 1% for whom the solution has caused >> another problem. Luckily, there are simple fixes available for you. You >> can pin the version of Cheetah in your package to match that in ZopeSkel >> (which is what you've done). Or you can remove the explicit dependency on >> Cheetah and allow the dependency in ZopeSkel to install it for you. >> >> As >> http://www.coactivate.org/projects/zopeskel-bbq-sprint/blog/2009/10/03/zopeskel-bbq-sprint-day-one/ >> the blog post linked above states, we agree that the fix should be >> upstream. We have plans to move on to making that fix next. If you have >> the time, we'd welcome your help in getting Markdown repaired so that it can >> be installed in python 2.4. As soon as that fix is made, we will unpin >> ZopeSkel and everyone can go along their merry way. >> >> Thanks, >> >> c > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > > > ------------------------------------------------------------------------ > > _______________________________________________ > Plone-Users mailing list > Plo...@li... > https://lists.sourceforge.net/lists/listinfo/plone-users -- -- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF |
|
From: Yuri T. <qar...@gm...> - 2009-10-10 21:59:40
|
Waylan released a new version (2.0.3) a few days ago. Did this fix the problem? - yuri On Sat, Oct 10, 2009 at 4:19 PM, kiorky <ki...@cr...> wrote: > Hi waylan, > Any Status ... !? > > kiorky a écrit : >> Hi Waylan, >> >> Some news from python24 packaging front ;). >> >> Attached patch make your Markdown package python-2.4 friendly. >> Feel free to merge/release it. >> >> The enjoying console output from the new dist and python 2.4: >> >> (test)kiorky@judith ~/projects/repos/python-markdown $ easy_install >> dist/Markdown-2.0.3.zip >> Processing Markdown-2.0.3.zip >> ... >> Installed >> /home/kiorky/projects/repos/python-markdown/test/lib/python2.4/site-packages/Markdown-2.0.3-py2.4.egg >> Processing dependencies for Markdown==2.0.3 >> Searching for elementtree >> ... >> Adding elementtree 1.2.7-20070827-preview to easy-install.pth file >> Installed >> ... >> Finished processing dependencies for Markdown==2.0.3 >> >> (test)kiorky@judith ~/projects/repos/python-markdown $ python -c "import >> markdown;print markdown.version" >> 2.0.3 >> >> >> cewing a écrit : >>> kiorky wrote: >>>> I think the fix must be upstream and the author is quite responsive, >>>> just advertise him (i already did a bit earlier and im waiting for >>>> response). >>>> >>> As it turns out, we agree with your assessment completely. The problem lies >>> upstream and should properly be fixed there. There's quite a decent >>> analysis of the problem in >>> http://www.coactivate.org/projects/zopeskel-bbq-sprint/blog/2009/10/03/zopeskel-bbq-sprint-day-one/ >>> this blog post from the first day of the zopeskel spring (underway right >>> now). >>> >>> However, the installation of ZopeSkel 2.12 under python 2.4 was broken and >>> as it is used widely in the zope/plone world, leaving it in that state until >>> an upstream fix is made is not an option. We repaired the problem with >>> ZopeSkel by pinning a version of Cheetah that avoids the whole mess. This >>> will solve a truly bad problem for 99% of the folks who use ZopeSkel. >>> >>> It appears that you are in the remaining 1% for whom the solution has caused >>> another problem. Luckily, there are simple fixes available for you. You >>> can pin the version of Cheetah in your package to match that in ZopeSkel >>> (which is what you've done). Or you can remove the explicit dependency on >>> Cheetah and allow the dependency in ZopeSkel to install it for you. >>> >>> As >>> http://www.coactivate.org/projects/zopeskel-bbq-sprint/blog/2009/10/03/zopeskel-bbq-sprint-day-one/ >>> the blog post linked above states, we agree that the fix should be >>> upstream. We have plans to move on to making that fix next. If you have >>> the time, we'd welcome your help in getting Markdown repaired so that it can >>> be installed in python 2.4. As soon as that fix is made, we will unpin >>> ZopeSkel and everyone can go along their merry way. >>> >>> Thanks, >>> >>> c >> >> >> ------------------------------------------------------------------------ >> >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry® Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart your >> developing skills, take BlackBerry mobile applications to market and stay >> ahead of the curve. Join us from November 9-12, 2009. Register now! >> http://p.sf.net/sfu/devconf >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Plone-Users mailing list >> Plo...@li... >> https://lists.sourceforge.net/lists/listinfo/plone-users > > -- > -- > Cordialement, > KiOrKY > GPG Key FingerPrint: 0x1A1194B7681112AF > > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Python-markdown-discuss mailing list > Pyt...@li... > https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss > > |
|
From: kiorky <ki...@cr...> - 2009-10-11 09:40:47
Attachments:
signature.asc
|
Hi,
The problem is fixed although the solution used is far for optimal and even
dirty for me:
* Duplication around current version, my pkg_resources call in the proposed
patch was not there to make things nicer, Think that if you want to use that,
you can't import the module with version bites in the setup.py because at
install time, your distribution will not be already registered with the
setuptools machinery and you will get some DistributionNotFoundError unless you
had a previous markdown installation (silent error).
* False commit messages
"""
Fixed a silly bug in setup.py. Importing version from the lib
requires that all dependencaies for the lib are present, so we
can't actuly import the lib until after we check for
dependencies - which means we can't import version in the setup
script. Grrr. We'll have to remember to update the version
number in both places from now on. Sigh.
"""
It's not true [1]. The real problem, i think was an ImportError at install
time (ElementTree?) resulting on an unavailability of the module. That was one
of the purposes of my provided patch also...
* Another error is to mixing setuptools and distutils, AFAIK, install_requires
is on setuptools side.
That may be why Waylan did not spoil me this new release.
[1] See how i can import things there and there.
(m)kiorky@judith ~/test $ tree
|-- mylib
| |-- __init__.py
| |-- version.py
`-- setup.py
(m)kiorky@judith ~/test $ cat setup.py
#!/usr/bin/env python
__docformat__ = 'restructuredtext en'
from setuptools import setup, find_packages
from mylib.version import version
setup(
name = 'mylib',
version = version,
packages = find_packages(),
include_package_data=True,
install_requires=["zc.buildout"],
)
# vim:set et sts=4 ts=4 tw=80:
(m)kiorky@judith ~/test $ cat mylib/version.py
version='1.0'
---------> sdist does not complain about mylib.version call
(m)kiorky@judith ~/test $ python setup.py sdist
running sdist
tar -cf dist/mylib-1.0.tar mylib-1.0
gzip -f9 dist/mylib-1.0.tar
removing 'mylib-1.0' (and everything under it)
----------> neither setuptools (Distribute there)
(m)kiorky@judith ~/test $ easy_install -U dist/mylib-1.0.tar.gz
...
Installed /home/kiorky/m/lib/python2.4/site-packages/mylib-1.0-py2.4.egg
...
Installed /home/kiorky/m/lib/python2.4/site-packages/zc.buildout-1.4.1-py2.4.egg
...
Finished processing dependencies for mylib==1.0
(m)kiorky@judith ~/test $ python -c "from mylib.version import version;print
version"
1.0
Yuri Takhteyev a écrit :
> Waylan released a new version (2.0.3) a few days ago. Did this fix the problem?
>
> - yuri
--
--
Cordialement,
KiOrKY
GPG Key FingerPrint: 0x1A1194B7681112AF
|
|
From: Waylan L. <wa...@gm...> - 2009-10-11 15:07:46
|
First, sorry for not responding directly to this message. As I've stated elsewhere, my connectivity has been very limited these past few weeks and probably will be for the next couple months. My normal dev box for this stuff is currently disassembled and in storage - making proper testing in all supported versions less than ideal. Like many open source projects, I do this in my spare time and sometimes life gets in the way. Second, I will add that while setuptools certainly has it's merits, I personally do not care for it and would prefer to not use it at all. For more specifics from someone smarter than me, I would suggest reading Ian Bicking's thoughts (among others) on setuptools (the creator of pip and virtualenv). Of course, at the same time I realize that others actually use easy_install regularly (including markdown users) so I make sure it works. However, that's about as far as I prefer to go. I saw your patch switched to using setuptools and I stopped reading. I could suggest that if someone provides a patch that allows use of various extended features of setuptools we would use it, but the fact is, I don't want to maintain it. Anyway, enough about me... On Sun, Oct 11, 2009 at 5:41 AM, kiorky <ki...@cr...> wrote: > Hi, > > The problem is fixed although the solution used is far for optimal and even > dirty for me: > > * Duplication around current version, my pkg_resources call in the proposed > patch was not there to make things nicer, I'm not crazy about the version number being defined in two places either. However, the fact is, that is how it was for some time - even before I joined the project. I more recently fixed that, but the dependency on ElemenTree was added even later. In fact, this is the first time this project has had any third party dependencies - so we're still ironing out a few things. I suppose it doesn't help that non of the core devs use older python versions that don't have ElementTree in the standard lib. We just test on an install of those versions which already have the dependency installed. > Think that if you want to use that, > you can't import the module with version bites in the setup.py because at > install time, your distribution will not be already registered with the > setuptools machinery and you will get some DistributionNotFoundError unless you > had a previous markdown installation (silent error). > > * False commit messages > """ > Fixed a silly bug in setup.py. Importing version from the lib > requires that all dependencaies for the lib are present, so we > can't actuly import the lib until after we check for > dependencies - which means we can't import version in the setup > script. Grrr. We'll have to remember to update the version > number in both places from now on. Sigh. > """ > It's not true [1]. The real problem, i think was an ImportError at install > time (ElementTree?) resulting on an unavailability of the module. That was one > of the purposes of my provided patch also... Exactly, the ImportError was from tying to import ElementTree, which failed because it was not installed yet. Obviously, the setup script can't import a module before it installs it - which was what my commit message was trying to convey in a roundabout sort of way. If someone can provide a better patch that doesn't use setuptools, I'll happily commit it. Oh, and my comment regarding the "silly error" was in regard to myself. It was silly of me to not recognize the potential for that error to occur. > * Another error is to mixing setuptools and distutils, AFAIK, install_requires > is on setuptools side. Not true. As part of a previous bug report, someone provided a patch that used install_requires and that was my initial thought. But then I checked the distutils docs and there is was, albeit, not documented very well. I should also point out that our documentation recommends that anyone on <2.5 run `easy_install elementtree` before `easy_install markdown`. That seems "good enough" for me. However, I realize that that may not be ideal for mass deployments across numerous systems using some automated mechanism - which is more likely the situation were people are stuck using those aging python versions. As as aside Ian Bicking's pip offers a much nicer solution to this problem IMO. > That may be why Waylan did not spoil me this new release. > Sorry, I don't follow your point with the rest of your message. It appears to be an attempt to impress me with the magic of setuptools. But that's the thing, too much magic isn't always better. Again, see pip for a less magical approach. If I misunderstood your intent, apologize. Regardless, we appreciate your feedback. -- ---- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg |
|
From: Waylan L. <wa...@gm...> - 2009-10-11 15:10:58
|
Oh, I should state that I am only stating my personal views on setuptools here. I do not know Yuri's position and will use whatever he prefers. This was simply an attempt to explain why I did what I did. On Sun, Oct 11, 2009 at 11:07 AM, Waylan Limberg <wa...@gm...> wrote: > First, sorry for not responding directly to this message. As I've > stated elsewhere, my connectivity has been very limited these past few > weeks and probably will be for the next couple months. My normal dev > box for this stuff is currently disassembled and in storage - making > proper testing in all supported versions less than ideal. Like many > open source projects, I do this in my spare time and sometimes life > gets in the way. > > Second, I will add that while setuptools certainly has it's merits, I > personally do not care for it and would prefer to not use it at all. > For more specifics from someone smarter than me, I would suggest > reading Ian Bicking's thoughts (among others) on setuptools (the > creator of pip and virtualenv). Of course, at the same time I realize > that others actually use easy_install regularly (including markdown > users) so I make sure it works. > > However, that's about as far as I prefer to go. I saw your patch > switched to using setuptools and I stopped reading. I could suggest > that if someone provides a patch that allows use of various extended > features of setuptools we would use it, but the fact is, I don't want > to maintain it. > -- ---- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg |
|
From: Yuri T. <qar...@gm...> - 2009-10-11 16:07:26
|
> Oh, I should state that I am only stating my personal views on > setuptools here. I do not know Yuri's position and will use whatever > he prefers. I am not sure if it really matters what my position is, given my recent lack of involvement with this project. But what it's worth, I agree with Waylan that we do not want our default installation scripts to assume setuptools. Defining the version number in two places is a small price to pay for avoiding this additional dependency. - yuri |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X