Michael Watkins wrote:

>>I've been playing around a bit with Quixote, Durus, and Dulcinea. I'm
>>working on a variety of BSD-based machines (NetBSD, FreeBSD, OS X), and I
>>noticed that there are two Linux-specific hacks in Dulcinea. I don't know
>>
>>
>
>I think Dulcinea users should speak up and let the group know there are
>some of us out there... my sense is there may be more than they realize.
>:-D
>
>

I *would* use Dulcinea if it had more documentation and exmples,
especially a "here's why this module is so useful, and here's its
problems...".  Otherwise I just look at a module quickly to see how it
does things, then write a simpler module that doesn't depend on all the
Dulcinea infrastructure (e.g., type checking).

>Along the same vein there are some other OS-specific paths in Dulcinea:
>
>Dulcinea: change start of site management scripts from
> #!/usr/bin/python
>to:
> #!/usr/bin/env python
>
>Why: default path on BSD, FreeBSD at least, is /usr/local/bin/python. I
>just symlink it but always at upgrade time its a detail that tends to get
>overlooked.
>
>

David Binger wrote:

> I think these are actually /www/python/bin/python in the distribution,
> and
> distutils modifies the !# line when you run the setup.py.
> I don't know the details.


Yes, distutils does this, and it's annoying.  If you later install
another version of Python in a different directory and expect the
program to choose the first Python in your path, haha it doesn't.

The "correct" default for the shbang line is:
#!/usr/bin/env python
because that usually does the right thing on "most" operating systems,
no matter where your favorite Python version  is located.  However, if
it's a distutils-managed program, I would just let distutils mangle it
rather than have one package that tries to do things differently.

David Binger wrote:

> If I remember right, the /usr/bin/env form
> is not replaced by distutils, and I guess that is a problem
> for Windows users.


That may be.  If so, it's good that distutils doesn't touch it.  Yes it
has to be changed on Windows, but the alternative is a Windows-specific
path that everybody else has to change.  If you consider that we're
really working around a deficiency in Windows ("hey, even Mac does it
the standard way now!"), the argument for coddling Windows doesn't make
a lot of sense.

Michael Watkins wrote:

>Dulcinea: start-scgi.py:
>Use a different approach to:
>  if os.path.exists("/usr/bin/tidy"):
>
>Again, default path is different on other *nixes. /usr/local/bin/tidy in
>the case of most (all?) BSDs.
>
>

/usr/local/bin is the default install location for almost all programs,
including Python.  The reason is, again, that "most" operating systems
reserve this space for sysadmin-installed programs.  OS-supplied
programs avoid this directory.  The reasoning is that if you're lazy or
a novice, you just accept the default, and you end up with a working
program, since /usr/local/bin is conveniently in the default path.  If
you want something specialized or you're building an OS package for
/usr/bin, you can change the location.  Perhaps tidy on BSD violates
this rule, or perhaps it was installed directly from source rather than
from the OS package.

I didn't look at the Dulcinea code, but the general approach is
    os.system("tidy")   # Let the shell look it up on the path.
or
   os.system("/usr/bin/env tidy")   # Mimics what the shell would do.
or
  TIDY = "/usr/bin/tidy"
  os.system(TIDY)

Sometimes I have to make a symlink in /usr/bin if a program insists on
looking there and nowhere else, but that can cause other problems if you
have a file unknown to the OS package manager in /usr/bin.  For one
thing it screws up a security audit: "Warning, /usr/bin/tidy does not
belong to any package."  It also means that if you install an OS package
with the same name, bye-bye symlink.  Or worse, /usr/local/bin/tidy gets
overwritten.

Usually I make symlinks the other way:
   /usr/local/bin/program  -> /opt/my/special/location/bin/program
to get the program into the path.