Hello, I needed support in easy_install for installing from HTTP digest and basic authenticated sites so I wrote the included patch. It currently supports specifying username and password information at the command line (however misguided that may be) and prompting the user interactively. It should also be easy to integrate with graphical interfaces. Please consider it for inclusion in the next release. Thanks, -- David D. Smith
At 01:25 PM 12/28/2006 +0900, David Smith wrote:
Hello,
I needed support in easy_install for installing from HTTP digest and basic authenticated sites so I wrote the included patch. It currently supports specifying username and password information at the command line (however misguided that may be) and prompting the user interactively. It should also be easy to integrate with graphical interfaces. Please consider it for inclusion in the next release.
Thanks for the submission, but for a number of reasons, I don't think it makes sense to put HTTP authentication directly into easy_install as a core feature. For version 0.7 and beyond, however, there will probably be some sort of plugin mechanism to enable alternative file transport protocols, so you should be able to plug this sort of thing in without patching easy_install in that case.
"Phillip J. Eby" <pje@telecommunity.com> writes:
At 01:25 PM 12/28/2006 +0900, David Smith wrote:
Hello,
I needed support in easy_install for installing from HTTP digest and basic authenticated sites so I wrote the included patch. It currently supports specifying username and password information at the command line (however misguided that may be) and prompting the user interactively. It should also be easy to integrate with graphical interfaces. Please consider it for inclusion in the next release.
Thanks for the submission, but for a number of reasons, I don't think it makes sense to put HTTP authentication directly into easy_install as a core feature.
For version 0.7 and beyond, however, there will probably be some sort of plugin mechanism to enable alternative file transport protocols, so you should be able to plug this sort of thing in without patching easy_install in that case.
Thanks a lot for responding so fast. Hmm, while I agree with you that this probably doesn't belong in core, I do strongly believe it belongs in the HTTP support whether that support is refactored into a separate module for 0.7 or in its current form. The usecase is too obvious: using setuptools for distribution of modules that are not publically available, such as commercial or pre-release development. Until 0.7 is released, considering the very small size of the patch, could we add this for now and refactor it later? Thanks, -- David D. Smith
At 03:12 PM 12/28/2006 +0900, David Smith wrote:
The usecase is too obvious: using setuptools for distribution of modules that are not publically available, such as commercial or pre-release development.
If they're not publically available, why use authenticated HTTP at all? Among the many alternatives that work with easy_install today are: * rsync-mirrored directories * NFS-mounted directories * ssh-transport SVN servers (you even get prompted for your credentials!) * proxied HTTP And in a lot of cases, one or more of the above is either already set up or easier to add than a password-protected web directory. It seems to me that the only case where HTTP auth helps is if you were already distributing your files that way.
Until 0.7 is released, considering the very small size of the patch, could we add this for now and refactor it later?
0.6 is in a bugfix-only mode at the moment. It *may* get some extra features in the bootstrapping system (ez_setup) before the final release, but that's basically it. Please note that if you want to add this feature, nothing is stopping you from subclassing PackageIndex and creating an easy_install() instance that uses an instance of your subclass. This can be done without any patching; you would simply do something like this:: class MyPackageIndex(PackageIndex): # ... class my_easy_install(easy_install): create_index = MyPackageIndex # makes it use your class instead # ... And then either write your own version of the 'main()' function, or monkeypatch your class in. Add a setup.py to your little package to specify an entry point, and your easy_install command-line replacement is good to go. If your main concern is for your projects that use setuptools, you don't even need the main() function. Just specify: cmdclass = dict(easy_install=my_easy_install), in your setup() call to tell setuptools to use your replacement class. In other words, you don't need to have this patch accepted in order to integrate the functionality with the existing system. It's just not a nice orthogonal plugin, as you have to supply replacement subclasses in the normal distutils style, instead of entry points in the setuptools style.
"Phillip J. Eby" <pje@telecommunity.com> writes:
At 03:12 PM 12/28/2006 +0900, David Smith wrote:
The usecase is too obvious: using setuptools for distribution of modules that are not publically available, such as commercial or pre-release development.
If they're not publically available, why use authenticated HTTP at all? Among the many alternatives that work with easy_install today are:
* rsync-mirrored directories * NFS-mounted directories * ssh-transport SVN servers (you even get prompted for your credentials!) * proxied HTTP
I believe HTTP authenticated subversion is more common than all of the above. Additionally, the proxied HTTP support also lacks authentication support, which the patch rectifies.
It seems to me that the only case where HTTP auth helps is if you were already distributing your files that way.
I think you'd agree that HTTP is by far the most standard distribution method than any of the others currently supported by setuptools. We're really not talking about a special case.
In other words, you don't need to have this patch accepted in order to integrate the functionality with the existing system.
I admit it's easy enough to fix locally; that's what I had been doing. The problem I have with that is it's not a special case and if you support ssl-encrypted HTTP, you should also support HTTP authentication considering how the two are often used together. Thanks, -- David D. Smith
I forgot to mention that I am not seeking this to get included in the stable 0.6 branch. Apply to current 0.7 SVN and refactor later is what I wanted to say. -- David D. Smith
We'd really like to see authenticated HTTP as well. In our case we have eggs which are not publicly available, but would like to distribute them to our customers. Bryce David Smith wrote:
"Phillip J. Eby" <pje@telecommunity.com> writes:
At 03:12 PM 12/28/2006 +0900, David Smith wrote:
The usecase is too obvious: using setuptools for distribution of modules that are not publically available, such as commercial or pre-release development.
If they're not publically available, why use authenticated HTTP at all? Among the many alternatives that work with easy_install today are:
* rsync-mirrored directories * NFS-mounted directories * ssh-transport SVN servers (you even get prompted for your credentials!) * proxied HTTP
I believe HTTP authenticated subversion is more common than all of the above. Additionally, the proxied HTTP support also lacks authentication support, which the patch rectifies.
It seems to me that the only case where HTTP auth helps is if you were already distributing your files that way.
I think you'd agree that HTTP is by far the most standard distribution method than any of the others currently supported by setuptools. We're really not talking about a special case.
In other words, you don't need to have this patch accepted in order to integrate the functionality with the existing system.
I admit it's easy enough to fix locally; that's what I had been doing. The problem I have with that is it's not a special case and if you support ssl-encrypted HTTP, you should also support HTTP authentication considering how the two are often used together.
Thanks,
------------------------------------------------------------------------
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
At 03:55 PM 12/28/2006 +0900, David Smith wrote:
"Phillip J. Eby" <pje@telecommunity.com> writes:
At 03:12 PM 12/28/2006 +0900, David Smith wrote:
The usecase is too obvious: using setuptools for distribution of modules that are not publically available, such as commercial or pre-release development.
If they're not publically available, why use authenticated HTTP at all? Among the many alternatives that work with easy_install today are:
* rsync-mirrored directories * NFS-mounted directories * ssh-transport SVN servers (you even get prompted for your credentials!) * proxied HTTP
Also, I forgot to mention password-protected FTP, which easy_install also supports (using ftp://user:pass@host URLs).
I believe HTTP authenticated subversion is more common than all of the above.
I've never set up svn-over-http before, as I find it a PITA compared to plain svn or svn-over-ssh. I guess tastes vary in this respect.
Additionally, the proxied HTTP support also lacks authentication support, which the patch rectifies.
It's relatively easy to add support for Basic auth with credentialed HTTP URLs, so that's what I've done. I'd rather not make easy_install interactive at this time, nor add one-shot user/password command line options, nor make the behavior dependent on the server's response. Using URLs with credentials also allows more than one set to be specified on the command line (or via dependency_links). The patch is minor enough that I added it to 0.6; it only affects URLs that would have caused today's easy_install to crash with an httplib.InvalidURL error, anyway. The easiest way to use it is to use a -f or dependency_links URL that points to a page with links to the actual downloads. As long as they are the same scheme and host, they'll inherit the credentials from the original URL.
The patch is minor enough that I added it to 0.6; it only affects URLs that would have caused today's easy_install to crash with an httplib.InvalidURL error, anyway.
The easiest way to use it is to use a -f or dependency_links URL that points to a page with links to the actual downloads. As long as they are the same scheme and host, they'll inherit the credentials from the original URL.
Trying this now, using setuptools-0.6c6dev_r54241, but I must be doing something wrong here, because I cannot get it to work. What I do is: easy_install -f \ https://user:secret@myhost.com/trac/wiki/PackageIndex SomePackage This index page requires authentication and easy_install can indeed read the index page with the supplied credentials. It finds the correct download URL too, i.e.: https://myhost.com/svn/somepackage#egg=SomePackage It was my understanding that easy_install would reuse the credentials as specified for the index page URL, since both host and scheme are identical for the download and index page URLs. However downloading fails, with a 401 Authorization Required error. As I said, it could very well be I'm doing something wrong here. Any hint is highly appreciated. kind regards, jw -- Jan-Wijbrand Kolman
Hi folks, I have an app that I'm using setuptools to build/install. During the build process (I think), it "touches" the following files: ... myapp/src/app/app.egg-info/PKG-INFO myapp/src/app/app.egg-info/SOURCES.txt myapp/src/app/app.egg-info/dependency_links.txt myapp/src/app/app.egg-info/requires.txt myapp/src/app/app.egg-info/top_level.txt ... even though none of the files in the app were modified. As a result the source control system thinks there are new versions of these files. THough they are not marked changed by the source control system, the fact that they are being flagged as being "tocuhed" is causing confusion amongst folks in my team unrelated to my comp - when they see that their changes elsewhere - is affecting my comp. Since these files are deployed as part of the install step, looks like they have to be included under source control. Is there a way to ask setuptools to not "touch" these files if nothing underlying has changed. I can understand SOURCES.txt would have to change when a new source file is added or an old one removed, but others in the above list pretty much remain the same within a given release. Thanks for the help, /venkat ____________________________________________________________________________________ Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A. http://answers.yahoo.com/dir/?link=list&sid=396545367
On Thu, 2007-04-05 at 11:00 -0700, Venkat Bommakanti wrote:
Hi folks,
I have an app that I'm using setuptools to build/install. During the build process (I think), it "touches" the following files: ... myapp/src/app/app.egg-info/PKG-INFO myapp/src/app/app.egg-info/SOURCES.txt myapp/src/app/app.egg-info/dependency_links.txt myapp/src/app/app.egg-info/requires.txt myapp/src/app/app.egg-info/top_level.txt ... even though none of the files in the app were modified. As a result the source control system thinks there are new versions of these files. THough they are not marked changed by the source control system, the fact that they are being flagged as being "tocuhed" is causing confusion amongst folks in my team unrelated to my comp - when they see that their changes elsewhere - is affecting my comp.
Since these files are deployed as part of the install step, looks like they have to be included under source control. Is there a way to ask setuptools to not "touch" these files if nothing underlying has changed.
I typically add the .egg-info folder to the "ignored" files in version control since the files in there will be automatically regenerated by the build process. Unless you have custom files that you put in the .egg-info folder (which I think is uncommon) you can probably just leave that folder out of version control too. BTW what version control is this? Most VC systems I've used are smart enough to only show files as "changed" if the content has changed, not just the timestamp. -- Matt Good
At 03:05 PM 4/5/2007 -0400, Matt Good wrote:
I typically add the .egg-info folder to the "ignored" files in version control since the files in there will be automatically regenerated by the build process. Unless you have custom files that you put in the .egg-info folder (which I think is uncommon) you can probably just leave that folder out of version control too.
That's correct. Only projects that explicitly put files under .egg-info need to track them in version control, because all the automatically generated files are regenerated from setup.py whenever any command that needs them is run.
Thanks, Matt & Philip. I'll get them out of source control - since those files were deployed in the installed egg, I thought they were needed to be under source control. Just like one can specify temp build & dist dirs to be used in the build/install process, is it possible to have setuptools place these files in a user-defined dir... that'd make it easy to implement the "make clean" equivalent to ensure these files don't show up as being "privtate" files in one's tree. Thanks, /venkat --- "Phillip J. Eby" <pje@telecommunity.com> wrote:
I typically add the .egg-info folder to the "ignored" files in version control since the files in there will be automatically regenerated by the build process. Unless you have custom files
At 03:05 PM 4/5/2007 -0400, Matt Good wrote: that you put in
the .egg-info folder (which I think is uncommon) you can probably just leave that folder out of version control too.
That's correct. Only projects that explicitly put files under .egg-info need to track them in version control, because all the automatically generated files are regenerated from setup.py whenever any command that needs them is run.
____________________________________________________________________________________ Bored stiff? Loosen up... Download and play hundreds of games for free on Yahoo! Games. http://games.yahoo.com/games/front
At 02:28 PM 4/5/2007 -0700, Venkat Bommakanti wrote:
Thanks, Matt & Philip.
I'll get them out of source control - since those files were deployed in the installed egg, I thought they were needed to be under source control.
Just like one can specify temp build & dist dirs to be used in the build/install process, is it possible to have setuptools place these files in a user-defined dir... that'd make it easy to implement the "make clean" equivalent to ensure these files don't show up as being "privtate" files in one's tree.
See the egg_info command options, but please note that "setup.py develop" and "setup.py test" will not work correctly unless the .egg-info directory is in its default location. So, if you can live with that limitation, yes, you can change where the egg-info lives. If not, then the answer is no.
participants (6)
-
Bryce Hendrix -
David Smith -
Jan-Wijbrand Kolman -
Matt Good -
Phillip J. Eby -
Venkat Bommakanti