Hi; trying to get back into this again... So, there's a package at http://svn.saddi.com/flup/trunk/ that I want to install, but it has no setup.py file. I think that file should look something like: from setuptools import setup setup(name="flup", packages=['flup', 'flup.middleware', 'flup.resolver', 'flup.server'] version='0.0-devel-r???') And I'd probably add other things, but I think that's all that's required. So... how should I make this happen? Should I hardcode 'http://svn.saddi.com/flup/trunk' into the setup.py file? Can I make the location overrideable with an option? How do I download the checkout? What was in a function before is now in setuptools.package_index.PackageIndex, and involves all sorts of data that doesn't seem to imply (because it's not a package without the setup.py file, and there's no index to get it from). Should I calculate r??? on my own, and if so where? Right before I call setup()? I need the repository location to do so, so if the repository location was overrideable then I'd need to get the real location. Once the files are checkout out, how do I put it in place? Is there a way to set the "base path" for the packages, so I could say "install these packages, found in /tmp/wherever-it-was-downloaded-to"? -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org
At 06:01 PM 7/3/2005 -0500, Ian Bicking wrote:
Hi; trying to get back into this again...
So, there's a package at http://svn.saddi.com/flup/trunk/ that I want to install, but it has no setup.py file. I think that file should look something like:
from setuptools import setup setup(name="flup", packages=['flup', 'flup.middleware', 'flup.resolver', 'flup.server'] version='0.0-devel-r???')
And I'd probably add other things, but I think that's all that's required. So... how should I make this happen? Should I hardcode 'http://svn.saddi.com/flup/trunk' into the setup.py file? Can I make the location overrideable with an option? How do I download the checkout?
Why don't you just use a subversion "external" to include the package in your own as a subdirectory? Then use the package_dir setting in setup to refer to the subdirectory. You then publish your wrapping package as a subversion URL. This won't work for auto-discovery from PyPI unless your URL ends with Flup.egg or something like that, but you can always give it to EasyInstall as a URL, or build eggs and publish those.
What was in a function before is now in setuptools.package_index.PackageIndex, and involves all sorts of data that doesn't seem to imply (because it's not a package without the setup.py file, and there's no index to get it from).
Well, it still doesn't stop you from using it to download. Be aware also that the API for the non-downloading parts of PackageIndex might change significantly between now and 0.6, due to the redesign docs I posted here a week or two ago.
Should I calculate r??? on my own, and if so where? Right before I call setup()? I need the repository location to do so, so if the repository location was overrideable then I'd need to get the real location.
Note that bdist_egg has an option to pull this for you, although currently it uses the setup.py directory so that doesn't actually help in this case.
Once the files are checkout out, how do I put it in place? Is there a way to set the "base path" for the packages, so I could say "install these packages, found in /tmp/wherever-it-was-downloaded-to"?
I don't understand.
Phillip J. Eby wrote:
At 06:01 PM 7/3/2005 -0500, Ian Bicking wrote:
Hi; trying to get back into this again...
So, there's a package at http://svn.saddi.com/flup/trunk/ that I want to install, but it has no setup.py file. I think that file should look something like:
from setuptools import setup setup(name="flup", packages=['flup', 'flup.middleware', 'flup.resolver', 'flup.server'] version='0.0-devel-r???')
And I'd probably add other things, but I think that's all that's required. So... how should I make this happen? Should I hardcode 'http://svn.saddi.com/flup/trunk' into the setup.py file? Can I make the location overrideable with an option? How do I download the checkout?
Why don't you just use a subversion "external" to include the package in your own as a subdirectory? Then use the package_dir setting in setup to refer to the subdirectory.
I'd never looked at those before; that seems to be just right for this. In other cases I might just download the file(s) on my own (e.g., archives online, etc.).
You then publish your wrapping package as a subversion URL. This won't work for auto-discovery from PyPI unless your URL ends with Flup.egg or something like that, but you can always give it to EasyInstall as a URL, or build eggs and publish those.
Yes. Hmm... I suppose I could create something that redirected from a detectable URL to the actual URL. That's kind of hacky though. Only being able to list actual eggs decreases the utility of a custom index. Could it also look at title attributes or something? It would be neat if you could download a working development copy with easy_install too. I'd like to encourage, or at least assist, people who want to interact with the code itself; and if you use a checkout you can at least use things like svn diff, even if you can't necessarily commit.
Should I calculate r??? on my own, and if so where? Right before I call setup()? I need the repository location to do so, so if the repository location was overrideable then I'd need to get the real location.
Note that bdist_egg has an option to pull this for you, although currently it uses the setup.py directory so that doesn't actually help in this case.
Cool... though yes, it wouldn't work quite right here.
Once the files are checkout out, how do I put it in place? Is there a way to set the "base path" for the packages, so I could say "install these packages, found in /tmp/wherever-it-was-downloaded-to"?
I don't understand.
Nevermind that, I think externals will work for me. -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org
On Jul 4, 2005, at 1:47 AM, Ian Bicking wrote:
Phillip J. Eby wrote:
You then publish your wrapping package as a subversion URL. This won't work for auto-discovery from PyPI unless your URL ends with Flup.egg or something like that, but you can always give it to EasyInstall as a URL, or build eggs and publish those.
Yes. Hmm... I suppose I could create something that redirected from a detectable URL to the actual URL. That's kind of hacky though. Only being able to list actual eggs decreases the utility of a custom index. Could it also look at title attributes or something?
It would be neat if you could download a working development copy with easy_install too. I'd like to encourage, or at least assist, people who want to interact with the code itself; and if you use a checkout you can at least use things like svn diff, even if you can't necessarily commit.
That's interesting. If you could point to subversion repositories from an index page, you could throw a page somewhere with a big list of project subversion URLs that use some kind of convention on naming... <a href="http://example.com/svn/foo/trunk/">foo-devel</a> <a href="http://example2.com/svn/bar/trunk/">bar-devel</a> such that $ easy_install.py foo-devel ... would grab and install the latest foo-devel from subversion. This would make a ton of sense in my development layout right now. Ryan Tomayko rtomayko@gmail.com http://naeblis.cx/rtomayko/
Phillip J. Eby wrote:
You then publish your wrapping package as a subversion URL. This won't work for auto-discovery from PyPI unless your URL ends with Flup.egg or something like that, but you can always give it to EasyInstall as a URL, or build eggs and publish those.
Ian Bicking wrote:
Yes. Hmm... I suppose I could create something that redirected from a detectable URL to the actual URL. That's kind of hacky though. Only being able to list actual eggs decreases the utility of a custom index. Could it also look at title attributes or something?
It would be neat if you could download a working development copy with easy_install too. I'd like to encourage, or at least assist, people who want to interact with the code itself; and if you use a checkout you can at least use things like svn diff, even if you can't necessarily commit.
Ryan Tomayko wrote:
That's interesting. If you could point to subversion repositories from an index page, you could throw a page somewhere with a big list of project subversion URLs that use some kind of convention on naming...
<a href="http://example.com/svn/foo/trunk/">foo-devel</a> <a href="http://example2.com/svn/bar/trunk/">bar-devel</a>
That's going to be ambiguous though, right. How do you know those URLs are subversion repositories without having to go out and HEAD each resource or something. We can use the rel attribute: <a href="http://example.com/svn/foo/trunk/" rel="subversion"> foo-devel </a> From the HTML 4.01 specification, rel attribute [1]:
This attribute describes the relationship from the current document to the anchor specified by the href attribute. The value of this attribute is a space-separated list of link types.
From the HTML 4.01 specification, link-types [2]:
Authors may wish to define additional link types not described in this specification. If they do so, they should use a profile to cite the conventions used to define the link types. Please see the profile attribute of the HEAD element for more details.
[1]: http://www.w3.org/TR/REC-html40/struct/links.html#adef-rel [2]: http://www.w3.org/TR/REC-html40/types.html#type-links Ryan Tomayko rtomayko@gmail.com http://naeblis.cx/rtomayko/
At 03:51 AM 7/4/2005 -0400, Ryan Tomayko wrote:
Phillip J. Eby wrote:
You then publish your wrapping package as a subversion URL. This won't work for auto-discovery from PyPI unless your URL ends with Flup.egg or something like that, but you can always give it to EasyInstall as a URL, or build eggs and publish those.
Ian Bicking wrote:
Yes. Hmm... I suppose I could create something that redirected from a detectable URL to the actual URL. That's kind of hacky though. Only being able to list actual eggs decreases the utility of a custom index. Could it also look at title attributes or something?
It would be neat if you could download a working development copy with easy_install too. I'd like to encourage, or at least assist, people who want to interact with the code itself; and if you use a checkout you can at least use things like svn diff, even if you can't necessarily commit.
Ryan Tomayko wrote:
That's interesting. If you could point to subversion repositories from an index page, you could throw a page somewhere with a big list of project subversion URLs that use some kind of convention on naming...
<a href="http://example.com/svn/foo/trunk/">foo-devel</a> <a href="http://example2.com/svn/bar/trunk/">bar-devel</a>
That's going to be ambiguous though, right. How do you know those URLs are subversion repositories without having to go out and HEAD each resource or something.
We can use the rel attribute:
<a href="http://example.com/svn/foo/trunk/" rel="subversion"> foo-devel </a>
Um, yeah. You guys probably haven't noticed this, but EasyInstall detects links using a regular expression that looks for "href="; it doesn't even try to parse HTML, and I don't really want it to start trying, either. It'd be better if we could put the information in the URL itself, e.g. "http://example.com/svn/foo/trunk#egg=foo_devel". IOW, I could have EasyInstall extract information from a specially-formatted "fragment" portion of a URL, which should be safe because it doesn't get transmitted to the server. EasyInstall already knows when it fetches a subversion http: URL, and automatically does a checkout in that case. Of course, the only current use case for such fragment identifiers is to mark a non-egg URL as a discoverable subversion checkout. For this purpose, EasyInstall really needs to know the effective version number, unless it just treats subversion checkouts as being the highest possible version number for purposes of selecting a download target. Either that, or the development checkout of a project needs to be treated as a project with a different name. For example, the development project for "foo" could be "foo_devel", and therefore installing "foo_devel" gives you something different. Or, there could be a command-line option to EasyInstall (--develop, perhaps) that requests subversion checkouts take precedence over other kinds of links (so that they don't have to have a version number in the link). In this case, we could make the fragment syntax be something like "#svn=foo" to indicate that the link is a subversion checkout for the "foo" project. Okay, so here's the idea. I add #svn=projectname detection support, but treat such links as the lowest possible version number (an empty version), unless the --develop flag is supplied or the fragment includes a version number. In this way, subversion links are always discoverable but not used unless they are either the only link and you have no version installed, or the person creating the link has identified the version. But with the --develop flag, what happens is that instead of installing the package and its dependencies, you just check out the named package(s) to a directory (or directories) named for the project under(s) your designated --build directory. It then runs a "setup.py develop" command on each of the checked-out projects to create links and script wrappers in your --install directory, so that you can use them. The "develop" command (which doesn't exist yet, but which I'd originally planned to write this weekend) installs an .egg-link file in the target directory that points to the development source root, and runs 'build_ext -i' to build any C extensions in-place, so they'll run from the source directory. Oh, and it also updates the project .egg-info so that it's usable as an egg, and puts stub scripts in the --script-dir that run the original source scripts after the appropriate 'require()' operation(s). This then allows you to develop in one directory, while having that code "deployed" to another. (In fact, you can have your development checkout deployed to multiple target locations at the same time, if desired.) There would also be an --uninstall flag for the develop command to let you remove the wrappers and .egg-link, so that you could then install a non-development version to the target. Anyway, a --develop option for EasyInstall could be added in order to run "setup.py develop" on checked-out development versions of packages you're working on, using EasyInstall's --install-dir and --script-dir as the base for the "develop" commands. I'm also planning, by the way, to update setuptools' "test" command to support running from a built egg; right now it still does a traditional distutils "install" instead.
participants (3)
-
Ian Bicking -
Phillip J. Eby -
Ryan Tomayko