"Phillip J. Eby" <[EMAIL PROTECTED]> writes: > At 09:14 PM 5/15/2007 +0100, Alexander Schmolck wrote: >>"Phillip J. Eby" <[EMAIL PROTECTED]> writes: >>Will do. But wouldn't it make sense to be able to specify the version name in >>this place to? > > Well, the version is a distribution level option; it can't be specified in > setup.cfg. That's a distutils thing, I'm afraid.
Why can't [egg_info] just grow a 'version' field? Due to the way the code is organized? I don't really understand why, logically, the .dev suffix is not distribution level -- it forms part of the .egg version (and what can be required/queried by other packages) after all... > > Btw, I erred in one point in my last email, your setup.cfg should actually > read: > > [egg_info] > tag_svn_revision = 1 > tag_build = .dev > > Note the extra '.' - this ensures that if you have something like '1.1a' as > your version, you won't end up with '1.1adev' as your version. Thanks, corrected > > >> > Where 'MyProjectname' is your setup(name=...) name. (I.e., the name of >> your >> > distribution.) >> >>Just to make sure because I'm not 100% clear on this and I think I have have >>come across conflicting information from different sources -- if my package is >>named scikits.mlabwrap and scikits is a namespace package, setup.py will have >>to look like so, right? >> >> setup(name='sckits.mlabwrap', # rather than just 'mlabwrap' >> namespace_packages=['scikits'] >> ... >> ) > > Uh, no. Your distribution name could be "Matlab Wrapper for SciKits" or > "FooBarBaz", for all the distutils or setuptools care. :) Project names > don't have any defined relationship to package names. For example the > "Importing" project on the Cheeseshop provides a module called > "peak.util.imports". OK, I see (I guess I must have been aware of that once). Maybe it would be good to state this somewhere were it's easy to find -- try searching for "name" on the setuptools page to see what I mean -- 'name' occurs in all sort of combinations and the first body text occurence is in <http://peak.telecommunity.com/DevCenter/setuptools#basic-use>, but I it's meaning is not further explained there. Maybe something like: "Note that the ``name = "HelloWorld"`` option has no other effect than specifiying what the distribtuion name of your package will be [[i.e. .egg name and cheeseshop?]]; in particular it is completely independent of the package name itself (i.e. the package import statement could in principle be ``import goodbye.cruel.world`` rather than ``import HelloWorld``)." or just name='HelloWorld' # what the project will be listed as in Cheeseshop >>and then ``require(scikits.mlabwrap)[0].version`` will get me the version >>number. > > You need quotes around the scikits.mlabwrap... or 'FooBarBaz', if that's your > project name. :) Yup, typo. >>As a suggestion: I think that the ``namespace_packages`` example for the >>ZoperInterface project at >><http://peak.telecommunity.com/DevCenter/setuptools#namespace-packages> >>would profit from adding the ``name=`` parameter, because it is not >>immediately obvious whether it should include the namespace_package or not. > > It's entirely unrelated - note that a project can contain multiple packages, > or even no packages at all. Actually mlabwrap itself once had several toplevel modules -- in distutils/pre-scikits days -- so as I said, I likely was once aware of this :) >>Thanks for all the info! I've tried to document the most important points >>about setuptools for other scikits developers, if you or someone else who's >>more knowledgable about setuptools wants to give some feedback (although it's >>obviously still work in progress), here's the url: >> >><http://projects.scipy.org/scipy/scikits/wiki/WikiStart#Scikitsuseofsetuptools> > > Reading that page, I'm not sure whether you want a scikits namespace package > in the first place. A namespace package is used to group several projects > under a single "owner", ala the various zope.* and peak.* and plone.* > packages. However, nobody but Zope Corp. should be releasing a zope.* > package, and nobody but me releasing a peak.* one. The whole point is to > "claim" a namespace for packages being released by a single owner - either > an organization or umbrella project. I think this holds true here (the umbrella community being scipy). Although the barriers for entry are lower than for scipy core, not anyone who feels like it can just create a scikits package -- for one thing someone needs to give you svn etc. access (somone = Jeff Strunk from enthought). > This corresponds to things like the org.apache' and 'com.sun' package > namespaces in Java - it's just a namespace to allow authors free rein to put > whatever modules and packages they like under that namespace. However, it > sounds from that page like scikits are independently created - which means > there's no need for a namespace package there, and in fact it's > counter-indicated for that situation! Well, independent as in not (necessarily) having mutual dependencies or requiring joint install (although pretty much all packages will need scipy or at least numpy) -- not as in having absolutely nothing to do with each other or being free for all. I think[1] an publication in a specilized journal run by a dedicated scientific community (say the ACM's APLers) might be vaguely analogous -- it provides a way for people who are interested in a particular niche to find pool and find relevant stuff that passed at least some weak form of peer-review to get to be associated with the ACM brand. > Also, may I suggest that rather than having a __version__ variable, why not > just have a get_version() function? The great advantage of __version__ is that it's standard. I personally frequently look up the version of an installed package by typing <MODULE>.__v<tab> and I'm seldomly disappointed; it wouldn't occur to me to look for a get_version function. > That way, you needn't import pkg_resources or do a require() as part of a > simple import operation. I hope it doesn't potentially take ages? For mlabwrap it wouldn't matter much (matlab takes ages to start up on import), but for other scikits this might be a problem. > Finally, it's not the case that you mustn't write a MANIFEST.in; setuptools > will use MANIFEST.in just fine. What setuptools *won't* do is rely on a > generated MANIFEST for anything; it always uses a freshly-generated internal > manifest, using MANIFEST.in + revision control info. Thus, it's impossible to > mess up setuptools with a stale MANIFEST file, the way you can with distutils. > (And if you're using CVS or SVN, you mostly won't need to bother with > MANIFEST.in.) OK, thanks for the clarification -- I've edited the webpage. cheers, 'as Footnotes: [1] The whole scikits stuff isn't my idea and its not fully fleshed out yet, so I'm just guessing wildly :) Robert Kern is more qualified to say something about the scope and aims of scikits. _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
