distutils-sig archive @ ASPN

Wall Street Pulse

Eliseo Messer (tkygroup@...)

Big News Expected Monday!

Infinex Ventures Inc. (INFX)
Price: 0.65
Up 18% on Friday the 9th alone
5 day expected price 1.90
Already started to climb.

This one did very well during last marketing campaign. Very Well!

OVERVIEW
Aggressive and energetic, Infinex boasts a dynamic and diversified portfolio of operations
across North America, with an eye on international expansion.

Grounded in natural resource exploration, Inifinex also offers investors access to exciting
new developments in the high-tech sector and the booming international real estate market.
Our market based experience, tenacious research techniques, and razor sharp analytical
skills allow us to leverage opportunities in emerging markets and developing technologies.

Identifying these opportunities in the earliest stages allows us to accelerate business
development and fully realize the company�s true potential. Maximizing overall
profitability and in turn enhancing shareholder value.

News

Infinex Announces Extension to Its Agreement in Chile
Infinex Ventures Inc. ("the Company") and its Board of Directors are pleased to announce
that the Company has received an extension (90 days) to its Agreement for the due diligence
period, in an effort to fully verify the offered title and all additional documentation,
including but not limited to, Trial C-1912- 2001 at the 14th Civil Court of Santiago and
Criminal Trial 1160-2002 at the 19th Court of Crime of Santiago of Chile, Ministry of Mines
of Chile over its sole and exclusive right to acquire a 50% interest in the Tesoro 1-12
Mining Claims.

Infinex Announces Joint Venture and Option Agreement Extension
Infinex Ventures Inc. and its Board of Directors are please to announce that the Company
has been granted an extension of 120 days to fulfill its contractual obligations under the
Joint Venture and Option Agreement dated June 14, 2004 on the Texada Island "Yew Group"
Mining Claims:

The Yew Claims are located on Texada Island, B.C. This region has a long history of mining
dating back to 1876. Several high grade copper gold skarns were mined in the area. The
geology of the Yew Claims can be found in MINFILE 092F/516.

keng liang gai hong nei zhong gan seng ru qi sao shang

Free website analysis worth $399

ntlink (ntlink@...)

You are receiving this message as an opt-in subscriber to Inscentral.net or one of our marketing partners.
If you no longer wish to receive further offers, please send an email with discontinue to:
Inscentral.net
27 Russel Ave
Edgewater, NJ
07020

calculate

recibos Regan... (hoyknnvetf@...)

Misuse causing
Winzip Espaol Plus ReGet
LISTSERV Maestro leading
colons

Re:

Selma Hester (tkyomqhgfbmnrftczfr@...)

BurnIn Lucifer

Sharp (knzaxpjaqz@...)

UATA SMARTUDM Password
Breakers salmon runBaby
Othello. Why A.A.L. Sep
OS/ Novell NetWare Linux
Happy all.
speeds repeated cycles.
Pioneer Philips Samsung Sharp
previous releases adds

keep an eye on this [NEWS] intersected gnat's bewhiskered

Qghumeay Nlfdxfi (cvscxggb857@...)

Infinex Ventures Inc. (INFX)
Current Price: 0.79

The Rally has begun
Watch this one like a hawk, this report is sent because the potential is 
incredible

H U G E  N E W S read below
S T R O N G  B U Y 

COMPANY OVERVIEW

Aggressive and energetic, Infinex boasts a dynamic and diversified 
portfolio of operations across North America, with an eye on 
international expansion. 

Grounded in natural resource exploration, Inifinex also offers investors 
access to exciting new developments in the high-tech sector and the 
booming international real estate market. Our market based experience, 
tenacious research techniques, and razor sharp analytical skills allow 
us to leverage opportunities in emerging markets and developing 
technologies. 

Identifying these opportunities in the earliest stages allows us to 
accelerate business development and fully realize the company.s true 
potential. Maximizing overall profitability and in turn enhancing 
shareholder value. 

Current Press Release

Infinex Announces Extension to Its Agreement in Chile
LAS VEGAS, NV, May 9 /PRNewswire-FirstCall/ - Infinex Ventures Inc. 
(INFX:OB - News; "the Company") and its Board of Directors are pleased 
to announce that the Company has received an extension (90 days) to its 
Agreement for the due diligence period, in an effort to fully verify the 
offered title and all additional documentation, including but not 
limited to, Trial C-1912- 2001 at the 14th Civil Court of Santiago and 
Criminal Trial 1160-2002 at the 19th Court of Crime of Santiago of 
Chile, Ministry of Mines of Chile over its sole and exclusive right to 
acquire a 50% interest in the Tesoro 1-12 Mining Claims.

Infinex Announces Joint Venture and Option Agreement Extension
LAS VEGAS, May 5 /PRNewswire-FirstCall/ - Infinex Ventures Inc. (INFX:OB 
- "the Company") and its Board of Directors are please to announce that 
the Company has been granted an extension of 120 days to fulfill its 
contractual obligations under the Joint Venture and Option Agreement 
dated June 14, 2004 on the Texada Island "Yew Gr0up" Mining Claims:


This is as sure as it gets, GET IN NOW



blat inquisitive cachalot disassembled discriminates encyclopedia's bronzed daffodils
Moliere freewheel Wallis incident dependability Beograd freewheel amounters hoariness
darning abreaction gangster glacier fruition easygoing adulthood bridgeheads discuss
encyclopedia's attained amazingly axon bouts lowest comparator airfield USAF correlation
microsecond's PVC

[Distutils] Upgrading eggs from custom url

Charlie Moad (cwmoad@...)

I am using setuptools to maintain
some plugins I wrote for a
python based protein viewer.  I would like to have another plugin that
simply checks for updates for the currently installed plugins.	Code
may help, so basically I would like to run:

from setuptools.command import easy_install
easy_install.main('-U MyPlugin'.split())

This would work fine if I registered my plugins on Pypi, but just
trust me that I shouldn't be pushing this junk up there yet.  I saw
the "dependency_links" option, and that is close to what I want. 
However, I would also like easy_install to check for an update to
"MyPlugin" there as well.

When issuing an "--upgrade" option, can the "download_url" be checked
automatically, or is there an existing way I can get a handle on that
"download_url" variable to pass to easy_install?  Any advice would be
appreciated.

Thanks,
      Charlie
_______________________________________________
Distutils-SIG maillist	-  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[Distutils] setuptools and site.py

Ian Bicking (ianb@...)

I'm trying to resolve a few issues in
working-env.py 
(http://svn.colorstudy.com/home/ianb/working-env.py) and I'm running 
into some conflicts with setuptools.

working-env.py basically works by creating another site.py, which 
doesn't add site-packages and other directories that I don't care for. 
Without setuptools this works pretty well.  But because of changes in 
setuptools, added right around the time I wrote working-env.py, 
setuptools now wants to write its own site.py and doesn't like mine.

One option is to integrate setuptools' changes into my own customized 
site.py, and then add __boot to the top to fake setuptools out.  I think 
that would be bothersome.

Another option would be if setuptools looked for something ahead of 
site.  Like, say, siteoverride.  Then I could put my siteoverride in 
place instead of site.py, let setuptools have site.py, and avoid the 
system site.py entirely.


Also, and this is related to a request Jim made a while ago, I'm 
monkeypatching setuptools currently to change the way it creates 
scripts, and it would be nice if this wasn't necessary.  Or was easier. 
  The monkeypatch is basically changing the script generated so that it 
sets sys.path before importing site.

Here's what I'm doing (in setuptools/__init__):

import setuptools.command.easy_install as easy_install

def get_script_header(script_text, executable=easy_install.sys_executable):
     from distutils.command.build_scripts import first_line_re
     first, rest = (script_text+'\n').split('\n',1)
     match = first_line_re.match(first)
     options = ''
     if match:
	 script_text = rest
	 options = match.group(1) or ''
	 if options:
	     options = ' '+options
     if options.find('-S') == -1:
	 options += ' -S'
     shbang = "#!%(executable)s%(options)s\n" % locals()
     shbang += ("import sys, os\n"
		"join, dirname = os.path.join, os.path.dirname\n"
		"lib_dir = join(dirname(dirname(__file__)), 'lib', 
'python%s.%s' % tuple(sys.version_info[:2]))\n"
		"sys.path.insert(0, lib_dir)\n"
		"import site\n")
     return shbang

easy_install.get_script_header = get_script_header






-- 
Ian Bicking  /	ianb@...  /  http://blog.ianbicking.org
_______________________________________________
Distutils-SIG maillist	-  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Further extending of setup.py

Ian Bicking (ianb@...)

Phillip J. Eby wrote:
> At 03:14 PM 4/19/2006 -0500, Ian Bicking wrote:
> 
>> It looks like, if I do this, it will also have to implement the 
>> current default behavior of finding distutils.commands providers.
> 
> 
> No it won't.	You should just look up things that you want to provide; 
> setuptools and distutils will do their own thing if your __contains__ 
> says False or your get() returns the default when they ask for a command 
> class.  They will then call your __setitem__ to cache whatever they find.

OK.

>>> If you come up with a nice "command map" object that lets you do 
>>> something like:
>>>	 setup(
>>>	     cmdclass = CommandMap(
>>>		 # configuration stuff here
>>>	     ),
>>>	     ...
>>>	 )
>>> then it would make a nice addition to setuptools for people that need 
>>> it.
>>
>>
>> OK, I'll look into that.  I'm guessing it'll be something like 
>> CommandMap([eggs]), and maybe some other options, though I can't think 
>> of any at the moment.  Maybe also reading .egg-info/command_map.txt if 
>> not given any list of eggs -- I'd like to keep options for putting 
>> metadata into .egg-info/*.txt files instead of setup.py.
> 
> 
> Yecch.  When I first started doing egg stuff for setuptools, I thought 
> it'd be nice to just edit files in .egg-info, and then I quickly got 
> sick of it.  IMO, setup.py should be a one-stop-shop.  It's easier to 
> explain to setup authors, too.  I can understand not wanting to go to 
> the trouble of implementing an egg_info "writer" plugin, but trying to 
> show people how to actually use these things, I think your users are a 
> lot better off if all they have to do is  pass in a setup keyword or two.

Putting things in setup.py means that those things are pretty opaque for 
tools.	For instance, when generating packages setup.py is a point of 
contention when you are creating a package that uses more than one 
.  If the generator was able to handle the specific files like 
entry_points.txt with knowledge of what those files meant, most 
contention could be avoided.  requires.txt is another thing that could 
be usefully manipulated with tools; for instance, if you had a tool that 
did commits to two projects at once, and updated the second project to 
require on the after-commit version of the first project.

So it's not the writer plugin that bothers me at all, though I haven't 
looked at the details of that.	It's that Python source is opaque.

Anyway, another thing occurred to me.  In addition to providing plain 
egg files, I'd like to allow egg+entry_point name to be a possible 
specifier.  It would be nice if we had a convention for how to specify 
both at once.  I'm using spec#entry_point_name in Paste, which works 
fine for me.

>> I think the features for a simple two-level command framework would be 
>> fairly simple:
>>
>> * Register commands somehow (entry points, I suppose).  Commands have 
>> a name and aliases.
>> * Commands can be called to run them, with all arguments after the 
>> command name.
>> * Commands have a help() method or something like that, that returns a 
>> string help message.  Probably two forms -- a long-form help, and 
>> short-form.	Maybe only the short form?
>> * The framework provides "cmd -h", "cmd help", "cmd -h subcommand", 
>> and "cmd help subcommand".  The last two might just call "cmd 
>> subcommand -h" internally.
>> * I suppose the framework needs to be given some global help message.
>> * It should be possible to hide commands or aliases from help.  E.g., 
>> commands that represent an internal interface, or aliases that are 
>> only provided for backward compatibility.
>> * Maybe a standard way to activate specific eggs, e.g., "cmd 
>> --require='Foo==1.0' ...".  Maybe also a way of controlling the 
>> PYTHONPATH, since setting environmental variables is not equally easy 
>> in all environments.
>>
>> Everything else should be possible to build from there with other 
>> sub-frameworks.
> 
> 
> You left out configuration.

Configuration...?  I don't see where that fits in?  Or, at least, I 
figured that configuration would be figured out by each subcommand, and 
they'd share command-line options for that by convention.

I did forget --version, though, which should be implemented in the 
parent command.

>> Self-referencing entry point loading would be nice.	Then, for 
>> instance, you could do:
>>
>>   entry_points="""
>>   [whatever.this.group.is]
>>   sql-setup = sqlobject.commands:setup_command
>>   """
>>
>> If setup_command is called with the package's Distribution object, 
>> then it can read config files or whatever from the egg, and you don't 
>> have to create little bits of glue all over the place.
>>
>> Hmm... putting information into the entry point name is problematic 
>> here, because SQLObject would give a set of commands which would be a 
>> bit tedious to enumerate, and it would be better if you could 
>> introduce the whole set of commands with one entry point.  Also, it 
>> doesn't resolve the problem of aliases.  Though it does give you an 
>> opportunity to resolve naming conflicts by renaming a command.
> 
> 
> Sorry, I don't really understand what you're trying to do here.  Are you 
> talking about adding something to "nest", or...?

Well, to be more specific, here's what I'd like for SQLObject:

* A setup.py command, like "setup.py sql-record".  This would take the 
current database schema as defined by the source, and write that out 
somewhere into the project's source (kept in the source as a historical 
record of all possible schemas the app has had.)

* The setup.py command has to figure out where to find SQLObject classes 
in the project, by some configuration.	I'd rather that configuration 
not go in setup.cfg, because it is used later...

* The SQLObject-using-application would get several subcommands:

   - create
   - drop
   - show-sql
   - status
   - upgrade

* These commands would read some configuration from the original egg, to 
find the history of schemas, and to find the module that holds the 
current SQLObject classes.

So, particularly in the second case, adding SQLObject to your 
application introduces a set of commands, and those commands can all run 
off the same configuration, which they also share with the setup.py command.

-- 
Ian Bicking  /	ianb@...  /  http://blog.ianbicking.org
_______________________________________________
Distutils-SIG maillist	-  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Further extending of setup.py

Phillip J. Eby (pje@...)

At 03:14 PM 4/19/2006 -0500, Ian
Bicking wrote:
>It looks like, if I do this, it will also have to implement the current 
>default behavior of finding distutils.commands providers.

No it won't.  You should just look up things that you want to provide; 
setuptools and distutils will do their own thing if your __contains__ says 
False or your get() returns the default when they ask for a command 
class.	They will then call your __setitem__ to cache whatever they find.


>>If you come up with a nice "command map" object that lets you do 
>>something like:
>>	setup(
>>	    cmdclass = CommandMap(
>>		# configuration stuff here
>>	    ),
>>	    ...
>>	)
>>then it would make a nice addition to setuptools for people that need it.
>
>OK, I'll look into that.  I'm guessing it'll be something like 
>CommandMap([eggs]), and maybe some other options, though I can't think of 
>any at the moment.  Maybe also reading .egg-info/command_map.txt if not 
>given any list of eggs -- I'd like to keep options for putting metadata 
>into .egg-info/*.txt files instead of setup.py.

Yecch.	When I first started doing egg stuff for setuptools, I thought it'd 
be nice to just edit files in .egg-info, and then I quickly got sick of 
it.  IMO, setup.py should be a one-stop-shop.  It's easier to explain to 
setup authors, too.  I can understand not wanting to go to the trouble of 
implementing an egg_info "writer" plugin, but trying to show people how to 
actually use these things, I think your users are a lot better off if all 
they have to do is  pass in a setup keyword or two.


>I think the features for a simple two-level command framework would be 
>fairly simple:
>
>* Register commands somehow (entry points, I suppose).  Commands have a 
>name and aliases.
>* Commands can be called to run them, with all arguments after the command 
>name.
>* Commands have a help() method or something like that, that returns a 
>string help message.  Probably two forms -- a long-form help, and 
>short-form.  Maybe only the short form?
>* The framework provides "cmd -h", "cmd help", "cmd -h subcommand", and 
>"cmd help subcommand".  The last two might just call "cmd subcommand -h" 
>internally.
>* I suppose the framework needs to be given some global help message.
>* It should be possible to hide commands or aliases from help.  E.g., 
>commands that represent an internal interface, or aliases that are only 
>provided for backward compatibility.
>* Maybe a standard way to activate specific eggs, e.g., "cmd 
>--require='Foo==1.0' ...".  Maybe also a way of controlling the 
>PYTHONPATH, since setting environmental variables is not equally easy in 
>all environments.
>
>Everything else should be possible to build from there with other 
>sub-frameworks.

You left out configuration.


>Self-referencing entry point loading would be nice.  Then, for instance, 
>you could do:
>
>   entry_points="""
>   [whatever.this.group.is]
>   sql-setup = sqlobject.commands:setup_command
>   """
>
>If setup_command is called with the package's Distribution object, then it 
>can read config files or whatever from the egg, and you don't have to 
>create little bits of glue all over the place.
>
>Hmm... putting information into the entry point name is problematic here, 
>because SQLObject would give a set of commands which would be a bit 
>tedious to enumerate, and it would be better if you could introduce the 
>whole set of commands with one entry point.  Also, it doesn't resolve the 
>problem of aliases.  Though it does give you an opportunity to resolve 
>naming conflicts by renaming a command.

Sorry, I don't really understand what you're trying to do here.  Are you 
talking about adding something to "nest", or...?


>Would setuptools stop using the distutils command framework?

No - it's necessary for compatibility, and to handle the intricate 
interdependencies where some commands depend on values computed by other 
commands.  Nest has much simpler needs that would be better served by less 
implicit coupling.

_______________________________________________
Distutils-SIG maillist	-  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig