[Zope-CMF] Re: License file question
Raphael Ritz, on 2008-05-29: > Not sure whether that's following best practice but here is > how paster/zopeskel generate this at the moment (this is taken > from a custom add-on I'm currently working on): > > [EMAIL PROTECTED]:~/dev/paster/incf.applications/trunk$ ls > docs incf incf.applications.egg-info README.txt setup.cfg setup.py > > [EMAIL PROTECTED]:~/dev/paster/incf.applications/trunk$ ls docs > HISTORY.txt INSTALL.txt LICENSE.GPL LICENSE.txt > > How do others handle this? I can understand putting the HISTORY in the toplevel docs/ directory of a package. But personally I like having it inside the "main" folder, so in your example above it would be incf.applications/incf/applications/HISTORY.txt That way when changing a file in the main directory and you want to change the history you do not need to descend three directories and go to docs/ to change that. And in bundles with svn externals the top level docs/ directory is not even visible because you only include the main folder. So you miss the history file (and the README.txt if you keep that in docs/ as well). I remember that at least once I changed something in a plone package inside a bundle, Wichert asked me to update the history file and I ended up wrongly updating the history file of CMFPlone because I never even saw the real history file belonging to that package. :-) -- Maurits van Rees | http://maurits.vanrees.org/ Work | http://zestsoftware.nl/ "This is your day, don't let them take it away." [Barlow Girl] ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: License file question
Jens Vagelpohl wrote: Hi Jens, Just wondering: Now that we are splitting the CMF down into its constituent packages and people don't need to get the old-fashioned tarball, do we need to have a copy of the LICENSE.txt file in every package? I'd think so, yes. And if yes, where would it go? It could go into each subpackage toplevel folder, where the setup.py resides, or down into the software folder where the other text files (README, CHANGES. etc) are located. Not sure whether that's following best practice but here is how paster/zopeskel generate this at the moment (this is taken from a custom add-on I'm currently working on): [EMAIL PROTECTED]:~/dev/paster/incf.applications/trunk$ ls docs incf incf.applications.egg-info README.txt setup.cfg setup.py [EMAIL PROTECTED]:~/dev/paster/incf.applications/trunk$ ls docs HISTORY.txt INSTALL.txt LICENSE.GPL LICENSE.txt How do others handle this? Raphael jens ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: License file question
Maurits van Rees wrote: Raphael Ritz, on 2008-05-29: Not sure whether that's following best practice but here is how paster/zopeskel generate this at the moment (this is taken from a custom add-on I'm currently working on): [EMAIL PROTECTED]:~/dev/paster/incf.applications/trunk$ ls docs incf incf.applications.egg-info README.txt setup.cfg setup.py [EMAIL PROTECTED]:~/dev/paster/incf.applications/trunk$ ls docs HISTORY.txt INSTALL.txt LICENSE.GPL LICENSE.txt How do others handle this? I can understand putting the HISTORY in the toplevel docs/ directory of a package. Btw, the zope.org convention is CHANGES.txt. See [1]. But personally I like having it inside the "main" folder, so in your example above it would be incf.applications/incf/applications/HISTORY.txt There's some benefit to that because it'll be part of the egg. That way when changing a file in the main directory and you want to change the history you do not need to descend three directories and go to docs/ to change that. One of the directories is largely superfluous: src. I think the only reason we have it is so that 'setup.py' isn't on the PYTHONPATH. Or something. And in bundles with svn externals the top level docs/ directory is not even visible because you only include the main folder. So you miss the history file (and the README.txt if you keep that in docs/ as well). I think a docs folder adds unnecessary structure in many cases. I remember that at least once I changed something in a plone package inside a bundle, Wichert asked me to update the history file and I ended up wrongly updating the history file of CMFPlone because I never even saw the real history file belonging to that package. :-) That's because bundles are stupid :) [1] http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/maintaining-software.txt ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: License file question
Wichert Akkerman, on 2008-05-29: > Previously Philipp von Weitershausen wrote: >> >But personally I like having it inside the "main" >> >folder, so in your example above it would be >> >incf.applications/incf/applications/HISTORY.txt >> >> There's some benefit to that because it'll be part of the egg. > > You probably want to use a MANIFEST.in anyway and that can easily be > used to include everything in doc/ or other places. A 'python setup.py sdist' will include the docs directory, as long as it is in subversion (and has at least one file in it). Aha, when you create an sdist in a subversion export (instead of a checkout) then the docs dir does not get included. Probably because setup.py does not point to it. With 'bdist_egg' the docs dir is indeed never included, unless you have it in MANIFEST.in. But I'm trying to avoid creating binary eggs at the moment. -- Maurits van Rees | http://maurits.vanrees.org/ Work | http://zestsoftware.nl/ "This is your day, don't let them take it away." [Barlow Girl] ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: License file question
Previously Maurits van Rees wrote: > Wichert Akkerman, on 2008-05-29: > > Previously Philipp von Weitershausen wrote: > >> >But personally I like having it inside the "main" > >> >folder, so in your example above it would be > >> >incf.applications/incf/applications/HISTORY.txt > >> > >> There's some benefit to that because it'll be part of the egg. > > > > You probably want to use a MANIFEST.in anyway and that can easily be > > used to include everything in doc/ or other places. > > A 'python setup.py sdist' will include the docs directory, as long as > it is in subversion (and has at least one file in it). And when someone installs from that sdist and there is no MANIFEST.in you suddenly end up with installs which are missing data files, zcml files or other things. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: License file question
On 29 May 2008, at 11:27 , Wichert Akkerman wrote: Previously Philipp von Weitershausen wrote: But personally I like having it inside the "main" folder, so in your example above it would be incf.applications/incf/applications/HISTORY.txt There's some benefit to that because it'll be part of the egg. You probably want to use a MANIFEST.in anyway and that can easily be used to include everything in doc/ or other places. Good point! ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: License file question
Previously Philipp von Weitershausen wrote: > >But personally I like having it inside the "main" > >folder, so in your example above it would be > >incf.applications/incf/applications/HISTORY.txt > > There's some benefit to that because it'll be part of the egg. You probably want to use a MANIFEST.in anyway and that can easily be used to include everything in doc/ or other places. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: License file question
Wichert Akkerman, on 2008-05-29: > Previously Maurits van Rees wrote: >> Wichert Akkerman, on 2008-05-29: >> > Previously Philipp von Weitershausen wrote: >> >> >But personally I like having it inside the "main" >> >> >folder, so in your example above it would be >> >> >incf.applications/incf/applications/HISTORY.txt >> >> >> >> There's some benefit to that because it'll be part of the egg. >> > >> > You probably want to use a MANIFEST.in anyway and that can easily be >> > used to include everything in doc/ or other places. >> >> A 'python setup.py sdist' will include the docs directory, as long as >> it is in subversion (and has at least one file in it). > > And when someone installs from that sdist and there is no MANIFEST.in > you suddenly end up with installs which are missing data files, zcml > files or other things. Is there a difference in that regard between easy installing an sdist or a bdist_egg? I would think/hope that the end result is the same. -- Maurits van Rees | http://maurits.vanrees.org/ Work | http://zestsoftware.nl/ "This is your day, don't let them take it away." [Barlow Girl] ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] CMF Tests: 9 OK
Summary of messages to the cmf-tests list. Period Wed May 28 11:00:00 2008 UTC to Thu May 29 11:00:00 2008 UTC. There were 9 messages: 9 from CMF Tests. Tests passed OK --- Subject: OK : CMF-1.6 Zope-2.8 Python-2.3.6 : Linux From: CMF Tests Date: Wed May 28 21:39:10 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-May/008894.html Subject: OK : CMF-1.6 Zope-2.9 Python-2.4.4 : Linux From: CMF Tests Date: Wed May 28 21:40:40 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-May/008895.html Subject: OK : CMF-2.0 Zope-2.9 Python-2.4.4 : Linux From: CMF Tests Date: Wed May 28 21:42:10 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-May/008896.html Subject: OK : CMF-2.0 Zope-2.10 Python-2.4.4 : Linux From: CMF Tests Date: Wed May 28 21:43:40 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-May/008897.html Subject: OK : CMF-2.1 Zope-2.10 Python-2.4.4 : Linux From: CMF Tests Date: Wed May 28 21:45:10 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-May/008898.html Subject: OK : CMF-2.1 Zope-2.11 Python-2.4.4 : Linux From: CMF Tests Date: Wed May 28 21:46:40 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-May/008899.html Subject: OK : CMF-trunk Zope-2.10 Python-2.4.4 : Linux From: CMF Tests Date: Wed May 28 21:48:11 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-May/008900.html Subject: OK : CMF-trunk Zope-2.11 Python-2.4.4 : Linux From: CMF Tests Date: Wed May 28 21:49:41 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-May/008901.html Subject: OK : CMF-trunk Zope-trunk Python-2.4.4 : Linux From: CMF Tests Date: Wed May 28 21:51:11 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-May/008902.html ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: License file question
Previously Maurits van Rees wrote: > Wichert Akkerman, on 2008-05-29: > > Previously Maurits van Rees wrote: > >> Wichert Akkerman, on 2008-05-29: > >> > Previously Philipp von Weitershausen wrote: > >> >> >But personally I like having it inside the "main" > >> >> >folder, so in your example above it would be > >> >> >incf.applications/incf/applications/HISTORY.txt > >> >> > >> >> There's some benefit to that because it'll be part of the egg. > >> > > >> > You probably want to use a MANIFEST.in anyway and that can easily be > >> > used to include everything in doc/ or other places. > >> > >> A 'python setup.py sdist' will include the docs directory, as long as > >> it is in subversion (and has at least one file in it). > > > > And when someone installs from that sdist and there is no MANIFEST.in > > you suddenly end up with installs which are missing data files, zcml > > files or other things. > > Is there a difference in that regard between easy installing an sdist > or a bdist_egg? I would think/hope that the end result is the same. Yes. If you make the bdist_egg from a svn checkout it includes all files that are in subversion. If you make an egg from something else like a sdist or a svn export that does not happen (since the svn information is not available). Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: License file question
Wichert Akkerman, on 2008-05-29: > Previously Maurits van Rees wrote: >> Wichert Akkerman, on 2008-05-29: >> > Previously Maurits van Rees wrote: >> >> Wichert Akkerman, on 2008-05-29: >> >> > Previously Philipp von Weitershausen wrote: >> >> >> >But personally I like having it inside the "main" >> >> >> >folder, so in your example above it would be >> >> >> >incf.applications/incf/applications/HISTORY.txt >> >> >> >> >> >> There's some benefit to that because it'll be part of the egg. >> >> > >> >> > You probably want to use a MANIFEST.in anyway and that can easily be >> >> > used to include everything in doc/ or other places. >> >> >> >> A 'python setup.py sdist' will include the docs directory, as long as >> >> it is in subversion (and has at least one file in it). >> > >> > And when someone installs from that sdist and there is no MANIFEST.in >> > you suddenly end up with installs which are missing data files, zcml >> > files or other things. >> >> Is there a difference in that regard between easy installing an sdist >> or a bdist_egg? I would think/hope that the end result is the same. > > Yes. If you make the bdist_egg from a svn checkout it includes all files > that are in subversion. If you make an egg from something else like a > sdist or a svn export that does not happen (since the svn information is > not available). Without a MANIFEST.in, the egg resulting from an sdist that is easy_installed is the same as a bdist_egg, right? Indeed when I try that for plone.portlet.static this is the case. So having a MANIFEST.in makes no real difference in that regard. One difference is that an sdist created from an svn *export* may not always be correct when there is no MANIFEST.in: when easy_installing an sdist created from a plone.portlet.static export, I got a complaint about a missing docs/HISTORY.txt as setup.py want to include that in the long_description of the egg. A bdist_egg created from that same export is fine. My conclusion is: as long as you remember to create an sdist or bdist_egg from an svn checkout, there is no need for a MANIFEST.in. There is one caveat: this will not include any empty directories in your package even though they are under svn control. A manifest file may help there. For reference, in the ploneout trunk only Products.PortalTransforms and Products.ExternalEditor have a MANIFEST.in file. -- Maurits van Rees | http://maurits.vanrees.org/ Work | http://zestsoftware.nl/ "This is your day, don't let them take it away." [Barlow Girl] ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: License file question
On May 29, 2008, at 04:19 , Philipp von Weitershausen wrote: [1] http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/maintaining-software.txt Ah, good resource, thanks for pointing that out. Thanks to everyone for the input. I'll go with putting the license file right with the software instead of into a docs folder at the top where setup.py resides. I find it more intuitive to have all documentation where the software is, and leave the "egg scaffolding" in a state where you don't have to touch anything "up high" once it's working. jens ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: License file question
Previously Maurits van Rees wrote: > Wichert Akkerman, on 2008-05-29: > > Previously Maurits van Rees wrote: > >> Wichert Akkerman, on 2008-05-29: > >> > Previously Maurits van Rees wrote: > >> >> Wichert Akkerman, on 2008-05-29: > >> >> > Previously Philipp von Weitershausen wrote: > >> >> >> >But personally I like having it inside the "main" > >> >> >> >folder, so in your example above it would be > >> >> >> >incf.applications/incf/applications/HISTORY.txt > >> >> >> > >> >> >> There's some benefit to that because it'll be part of the egg. > >> >> > > >> >> > You probably want to use a MANIFEST.in anyway and that can easily be > >> >> > used to include everything in doc/ or other places. > >> >> > >> >> A 'python setup.py sdist' will include the docs directory, as long as > >> >> it is in subversion (and has at least one file in it). > >> > > >> > And when someone installs from that sdist and there is no MANIFEST.in > >> > you suddenly end up with installs which are missing data files, zcml > >> > files or other things. > >> > >> Is there a difference in that regard between easy installing an sdist > >> or a bdist_egg? I would think/hope that the end result is the same. > > > > Yes. If you make the bdist_egg from a svn checkout it includes all files > > that are in subversion. If you make an egg from something else like a > > sdist or a svn export that does not happen (since the svn information is > > not available). > > Without a MANIFEST.in, the egg resulting from an sdist that is > easy_installed is the same as a bdist_egg, right? Indeed when I try > that for plone.portlet.static this is the case. So having a > MANIFEST.in makes no real difference in that regard. I'm not sure what you mean. The basic algorihm is: - MANIFEST is used to determine what is installed, or - subversion workingcopy information is used to determine what is installed, or - a default ruleset is used This algorithm is used at the moment a 'binary installation' is made, which is either when you build an egg using setup.py bdist_egg or when you install an egg from source (ie from a sdist or an unpacked tree). You can find full documentation on http://peak.telecommunity.com/DevCenter/setuptools Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: License file question
Wichert Akkerman, on 2008-05-29: > I'm not sure what you mean. The basic algorihm is: > > - MANIFEST is used to determine what is installed, or > - subversion workingcopy information is used to determine what is installed, > or > - a default ruleset is used > > This algorithm is used at the moment a 'binary installation' is made, > which is either when you build an egg using setup.py bdist_egg or when > you install an egg from source (ie from a sdist or an unpacked tree). I think we mean the same. :-) I was not sure whether you were implying that there is a difference between a bdist_egg and an sdist that is easy installed. Apparently you agree that there is no difference, with or without a MANIFEST.in. Well, there is the point of C extensions perhaps, where at least for Windows users a compiled, windows-specific binary egg is good to have. For all other use cases an sdist is fine. At least that seems to be the current train of throught in the Grokiverse. -- Maurits van Rees | http://maurits.vanrees.org/ Work | http://zestsoftware.nl/ "This is your day, don't let them take it away." [Barlow Girl] ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: License file question
Jens Vagelpohl, on 2008-05-29: > > On May 29, 2008, at 04:19 , Philipp von Weitershausen wrote: >> [1] >> http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/maintaining-software.txt > > Ah, good resource, thanks for pointing that out. > > Thanks to everyone for the input. I'll go with putting the license > file right with the software instead of into a docs folder at the top > where setup.py resides. I find it more intuitive to have all > documentation where the software is, and leave the "egg scaffolding" > in a state where you don't have to touch anything "up high" once it's > working. Suits me fine. Anyone in favour of updating the ZopeSkel templates to fit that pattern? (Sorry, bit out of topic here on the cmf list as there are no cmf skeletons there. Care to add one? :-)) -- Maurits van Rees | http://maurits.vanrees.org/ Work | http://zestsoftware.nl/ "This is your day, don't let them take it away." [Barlow Girl] ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: License file question
Previously Maurits van Rees wrote: > Jens Vagelpohl, on 2008-05-29: > > > > On May 29, 2008, at 04:19 , Philipp von Weitershausen wrote: > >> [1] > >> http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/maintaining-software.txt > > > > Ah, good resource, thanks for pointing that out. > > > > Thanks to everyone for the input. I'll go with putting the license > > file right with the software instead of into a docs folder at the top > > where setup.py resides. I find it more intuitive to have all > > documentation where the software is, and leave the "egg scaffolding" > > in a state where you don't have to touch anything "up high" once it's > > working. > > Suits me fine. Anyone in favour of updating the ZopeSkel templates to > fit that pattern? (Sorry, bit out of topic here on the cmf list as > there are no cmf skeletons there. Care to add one? :-)) -1 I want all documentation to be the first thing I see when I unpack something. I don't want to be forced to delve into 3 or 4 subdirectories. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: License file question
On May 29, 2008, at 08:34 , Wichert Akkerman wrote: Previously Maurits van Rees wrote: Suits me fine. Anyone in favour of updating the ZopeSkel templates to fit that pattern? (Sorry, bit out of topic here on the cmf list as there are no cmf skeletons there. Care to add one? :-)) -1 I want all documentation to be the first thing I see when I unpack something. I don't want to be forced to delve into 3 or 4 subdirectories. This is veering off course a little, a discussion about ZopeSkel handles this should probabably happen elsewhere ;-) I know how I'll proceed with the CMF packages. jens ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: License file question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wichert Akkerman wrote: > Previously Maurits van Rees wrote: >> Wichert Akkerman, on 2008-05-29: >>> Previously Maurits van Rees wrote: Wichert Akkerman, on 2008-05-29: > Previously Maurits van Rees wrote: >> Wichert Akkerman, on 2008-05-29: >>> Previously Philipp von Weitershausen wrote: > But personally I like having it inside the "main" > folder, so in your example above it would be > incf.applications/incf/applications/HISTORY.txt There's some benefit to that because it'll be part of the egg. >>> You probably want to use a MANIFEST.in anyway and that can easily be >>> used to include everything in doc/ or other places. >> A 'python setup.py sdist' will include the docs directory, as long as >> it is in subversion (and has at least one file in it). > And when someone installs from that sdist and there is no MANIFEST.in > you suddenly end up with installs which are missing data files, zcml > files or other things. Is there a difference in that regard between easy installing an sdist or a bdist_egg? I would think/hope that the end result is the same. >>> Yes. If you make the bdist_egg from a svn checkout it includes all files >>> that are in subversion. If you make an egg from something else like a >>> sdist or a svn export that does not happen (since the svn information is >>> not available). >> Without a MANIFEST.in, the egg resulting from an sdist that is >> easy_installed is the same as a bdist_egg, right? Indeed when I try >> that for plone.portlet.static this is the case. So having a >> MANIFEST.in makes no real difference in that regard. > > I'm not sure what you mean. The basic algorihm is: > > - MANIFEST is used to determine what is installed, or > - subversion workingcopy information is used to determine what is installed, > or > - a default ruleset is used > > This algorithm is used at the moment a 'binary installation' is made, > which is either when you build an egg using setup.py bdist_egg or when > you install an egg from source (ie from a sdist or an unpacked tree). setuptools-generated sdist tarballs made from SVN checkouts get all the correct files in them when made into eggs / installed via setuptools, using the metadata in the .egg-info directory (SOURCES.txt, in particular). I think the only issue is for folks who would like to install your packages without having setuptools present. Voluntarily using bare distutils is already so masochistic that I don't feel much pity for the added pain. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIPvyA+gerLs4ltQ4RArTOAJ41EZT9T5oCXhlOOetfheckYEzS9gCghto7 ZXOQYIjFxkfJzugcLN7Gb+Y= =vZQp -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] cmfuid and zope.app.intids
Hi, I was wondering if the CMFUid package could be replaced by a thin wrapper around zope.app.intids. As (I think) one of the few users of CMFUid, I'd like to replace it within something a little more robust and this seemed like a possible way to do it. Generally, I've found having the concept of uids available a very useful thing. So, my questions are: - Has anyone used zope.app.intids at all, or done anything similar? - Does this sound achievable at all? - Is this a generally useful thing to do? Thanks, Miles ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] cmfuid and zope.app.intids
On May 29, 2008, at 15:10 , Miles wrote: - Has anyone used zope.app.intids at all, or done anything similar? No to both - Does this sound achievable at all? I'd think so. - Is this a generally useful thing to do? From the standpoint of trying to prevent reinventing wheels all over the place it sounds like a good idea to re-use a Zope 3 component. However, beware of backwards-compatibility in terms of software and in terms of persistent data generated by the existing version. Like Tres always says, "persistence means always having to say you're sorry". Essentially, if you can do it while retaining backwards compatibility I'd be all for it. jens ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: cmfuid and zope.app.intids
Hi, From the standpoint of trying to prevent reinventing wheels all over the place it sounds like a good idea to re-use a Zope 3 component. However, beware of backwards-compatibility in terms of software and in terms of persistent data generated by the existing version. Like Tres always says, "persistence means always having to say you're sorry". Essentially, if you can do it while retaining backwards compatibility I'd be all for it. Hmm, this depends on how non-trivial or otherwise the upgrade steps can be, and what backwards compatibility is acceptable. I'd propose the following: - the existing uid classes remain with deprecation warnings until they can be removed, and also have a big "upgrade" button in the ZMI that turns them into the "new tool/utility" and imports existing data - once upgraded, IObjectAdded events fired by importing new content convert and register uids in the new scheme - instead of using the catalog, the "tool/utility" would actually retrieve the objects by oid, and then check permissions etc directly to mimic the CMF catalog (expires, allowedRolesAndUsers etc) - for BBB (default), the "tool/utility" would additionally annotate the objects with UidAnnotations (as currently) and these can be indexed in the catalog. this could be turned off by not registering an adapter (it's only needed for BBB I think) I suppose the slight deviation from BBB is that if someone is using a custom catalog (for example a "day-of-week-to-show" flag to provide random search results), they'll also need to provide some sort of customisation when objects are fetched by uid to get the same thing to happen. Given the number of people actually using CMFUid and the obscurity of the use-case, I think this might be acceptable to just document (and/or provide some sort of adapter-based customisation so it's easy). Does that sound BBB enough? I can't think of anything else that might break but that's what tests are for right :-) ? Miles ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: cmfuid and zope.app.intids
Miles wrote: Hi, I was wondering if the CMFUid package could be replaced by a thin wrapper around zope.app.intids. As (I think) one of the few users of CMFUid, I'd like to replace it within something a little more robust and this seemed like a possible way to do it. Generally, I've found having the concept of uids available a very useful thing. So, my questions are: - Has anyone used zope.app.intids at all, or done anything similar? Yes. There's a five.intid package for Zope 2 integration. This is used by plone.relations and plone.app.relations. The latter are actually very nice reference engine implementations (and not Plone specific as far as I'm aware). - Does this sound achievable at all? Yes. - Is this a generally useful thing to do? Yes, but beware of migration. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
