On Wednesday, March 16, 2011 9:03:19 PM UTC-4, bukzor wrote:
>
> I finally understand. You mean something along the lines of `kde-
> config`: an executable to help figure out the configuration at
> runtime. This requires either installation or control of the $PATH
> environment variable to work wel
If you just want to be unhappy about the current situation, I hereby
formally bestow upon you permission to be so. :)
The problem seems to be that you want to hook into the python process,
without hooking into the python process. Were this possible, it seems we
might have a serious security issu
On Mar 16, 3:29 pm, bukzor wrote:
> On Mar 15, 11:57 pm, "eryksun ()" wrote:
>
> > On Tuesday, March 15, 2011 12:44:48 AM UTC-4, bukzor wrote:
>
> > > Currently it requires either: 1) no symlinks to scripts or 2)
> > > installation of the pathtools to site-packages.
>
> > An executable with a uni
On Mar 15, 11:57 pm, "eryksun ()" wrote:
> On Tuesday, March 15, 2011 12:44:48 AM UTC-4, bukzor wrote:
>
> > Currently it requires either: 1) no symlinks to scripts or 2)
> > installation of the pathtools to site-packages.
>
> An executable with a unique name on the system PATH could be executed i
On Mar 16, 7:42 am, booklover wrote:
> > I'm going to try to get our solution open-sourced, then I'll get your
> > feedback on it.
>
> Thanks bukzor! I think that it would be very helpful to have a library
> like this available.
>
> In the longer term, what do people think about the possibility of
> I'm going to try to get our solution open-sourced, then I'll get your
> feedback on it.
Thanks bukzor! I think that it would be very helpful to have a library
like this available.
In the longer term, what do people think about the possibility of
writing up a PEP to fix this problem in the core
On Tuesday, March 15, 2011 12:44:48 AM UTC-4, bukzor wrote:
>
> Currently it requires either: 1) no symlinks to scripts or 2)
> installation of the pathtools to site-packages.
An executable with a unique name on the system PATH could be executed it as a
subprocess that pipes the configured base d
On Mar 15, 12:24 pm, booklover wrote:
> > Is everyone really happy with this?
>
> I'm not happy with this. In fact, if Python 3.3 came out with a
> solution for this problem, it would be a major motivation for me to
> migrate.
>
> I don't think that it would take much to fix either. Perhaps if Pyt
> Is everyone really happy with this?
I'm not happy with this. In fact, if Python 3.3 came out with a
solution for this problem, it would be a major motivation for me to
migrate.
I don't think that it would take much to fix either. Perhaps if Python
looked in the current directory for ".pth" file
On Tuesday, March 15, 2011 12:44:48 AM UTC-4, bukzor wrote:
> When looking at google code search, this kind of code is
> rampant (below). Is everyone really happy with this?
>
> sys.path.insert(0,
> os.path.dirname(os.path.dirname(
> os.path.dirname(os.path.abspath(__file__)
On Mar 14, 1:30 pm, "eryksun ()" wrote:
> On Monday, March 14, 2011 3:56:15 PM UTC-4, eryksun () wrote:
> > To be clear on the file structure, I'm picturing that 'base' is a
> > path on each user's shell path where all the accessible scripts
> > are linked, and that this is also the package direct
On 3/14/2011 4:31 PM, bruce bushby wrote:
but has anybody seen any
efforts to allow python to "import modules via a socket"
I do not remember any such thing.
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
On Monday, March 14, 2011 3:56:15 PM UTC-4, eryksun () wrote:
> To be clear on the file structure, I'm picturing that 'base' is a
> path on each user's shell path where all the accessible scripts
> are linked, and that this is also the package directory.
Wait, this won't work when the script is
I'm probably going off on a tangent here..but has anybody seen any
efforts to allow python to "import modules via a socket" ...rather
then just a "dir path" ?
On Mon, Mar 14, 2011 at 7:56 PM, eryksun () wrote:
> On Monday, March 14, 2011 9:45:51 AM UTC-4, eryksun () wrote:
> >
> > If you
On Monday, March 14, 2011 9:45:51 AM UTC-4, eryksun () wrote:
>
> If you're linking to a common file, couldn't you just add in
> the base folder there?
>
> ...
>
> # script.py
> import _path # _path.py is a symbolic link
>
> # _path.py:
> base = '/absolute/path/to/base'
> import site
> site.
On Monday, March 14, 2011 2:38:50 AM UTC-4, bukzor wrote:
> I've written this many times. It has issues. In fact, I've created a
> library for this purpose, for the following reasons.
If you're linking to a common file, couldn't you just add in the base folder
there? I don't think it's a bad pra
bukzor wrote:
We've been doing a fair amount of Python scripting, and now we have a
directory with almost a hundred loosely related scripts. It's
obviously time to organize this, but there's a problem. These scripts
import freely from each other and although code reuse is generally a
good thing
On Mar 13, 6:50 pm, Terry Reedy wrote:
> On 3/13/2011 7:27 PM, bukzor wrote:
>
>
>
>
>
>
>
>
>
> > I think this touches on my core problem. It's dead simple (and
> > natural) to use .py files simultaneously as both scripts and
> > libraries, as long as they're in a flat organization (all piled int
On Mar 13, 10:52 pm, "eryksun ()" wrote:
> On Sunday, March 13, 2011 7:27:47 PM UTC-4, bukzor wrote:
> > e) create custom boilerplate in each script that addresses the
> > issues in a-d. This seems to be the best practice at the moment...
>
> The boilerplate should be pretty simple. For examp
"bukzor" wrote
Let's walk through it, to make it more concrete:
1) we have a bunch of scripts in a directory
2) we organize these scripts into a hierarchy of directories. This
works except for where scripts use code that exists in a different
directory.
3) we move the re-used code causin
On Sunday, March 13, 2011 7:27:47 PM UTC-4, bukzor wrote:
> e) create custom boilerplate in each script that addresses the
> issues in a-d. This seems to be the best practice at the moment...
The boilerplate should be pretty simple. For example, if the base path is the
parent directory, the
On 3/13/2011 7:27 PM, bukzor wrote:
I think this touches on my core problem. It's dead simple (and
natural) to use .py files simultaneously as both scripts and
libraries, as long as they're in a flat organization (all piled into a
single directory). Because of this, I never expected it to be so
* bukzor [110313 15:48]:
>
> Thanks Tim.
>
> I believe I understand it. You create loaders in a flat organization,
> in the same directory as your shared library, so that it's found
Not in the same directory as shared libraries.
> naturally. These loaders use custom code to find and run the
On Mar 12, 12:37 pm, Tim Johnson wrote:
> * Phat Fly Alanna [110312 07:22]:
>
>
>
>
>
>
>
> > We've been doing a fair amount of Python scripting, and now we have a
> > directory with almost a hundred loosely related scripts. It's
> > obviously time to organize this, but there's a problem. These s
On Mar 12, 12:01 pm, "eryksun ()" wrote:
> bukzor wrote:
> > This only works if you can edit the PYTHONPATH. With thousands of
> > users and dozens of groups each with their own custom environments,
> > this is a herculean effort.
>
> ... I don't think it's recommended to directly run a script tha
* Tim Johnson [110312 10:41]:
<...> 3)Cut down on the number of executables by using 'loaderers'.
Sheesh! Typo, meant to say 'loaders'..
sorry
--
Tim
tim at johnsons-web.com or akwebsoft.com
http://www.akwebsoft.com
--
http://mail.python.org/mailman/listinfo/python-list
* Phat Fly Alanna [110312 07:22]:
> We've been doing a fair amount of Python scripting, and now we have a
> directory with almost a hundred loosely related scripts. It's
> obviously time to organize this, but there's a problem. These scripts
> import freely from each other and although code reuse
bukzor wrote:
> This only works if you can edit the PYTHONPATH. With thousands of
> users and dozens of groups each with their own custom environments,
> this is a herculean effort.
It works for me without setting PYTHONPATH. Again, I run the module from the
root folder with the -m option as a pa
On Mar 11, 10:14 pm, "eryksun ()" wrote:
> I'm not an expert at Python packaging, but assuming a structure such as
>
> folder1
> \
> __init__.py
> module1.py
> folder2
> \
> __init__.py
> module2.py
>
> within module1, I can import from module2, e.g.:
I'm not an expert at Python packaging, but assuming a structure such as
folder1
\
__init__.py
module1.py
folder2
\
__init__.py
module2.py
Then from the root folder I can run
python -m folder1.module1
and within module1, I can import from module2, e
We've been doing a fair amount of Python scripting, and now we have a
directory with almost a hundred loosely related scripts. It's
obviously time to organize this, but there's a problem. These scripts
import freely from each other and although code reuse is generally a
good thing it makes it quit
We've been doing a fair amount of Python scripting, and now we have a
directory with almost a hundred loosely related scripts. It's
obviously time to organize this, but there's a problem. These scripts
import freely from each other and although code reuse is generally a
good thing it makes it quit
32 matches
Mail list logo
