www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - rdmd and D equivalent for PYTHONPATH?

reply Chris Piker <chris hoopjump.com> writes:
Hi D

I've writing little test scripts using rdmd to understand what 
various functions are really doing (ex: .take(5)).  I'm up to the 
point where I need to write sample code to understand 
mir-algorithm a little better, but of course the library is not 
installed on my system.  So two related questions:

1) After a "git clone" and "dub build" I'm left with 
redistributables
    that need to be put ... somewhere. But where?  I tried this:

     cp -r -p source/mir /usr/local/include
     cp -p libmir-algorithm.a /usr/local/lib

    but no joy.  So where can I install libs so that rdmd will find
    them?

2) On a related topic, is there an environment variable I can set 
(similar
    to PYTHONPATH, MATLABPATH, IDL_PATH, etc.) or a config file I 
can alter
    that will add to the module include path?  I tried:



    at the top of the file, but that just hung rdmd and nothing 
ran.

Note: I'm aware of dub.  This isn't a question about dub.  I'm 
making scripts for local use, not redistributable binaries, so I 
would like to "install" mir-algorithm and similar libraries for 
my rdmd scripts to use.

Thanks for the help,
Mar 16 2021
parent reply Chris Piker <chris hoopjump.com> writes:
On Wednesday, 17 March 2021 at 03:43:22 UTC, Chris Piker wrote:


 Note: I'm aware of dub.  This isn't a question about dub.  I'm 
 making scripts for local use, not redistributable binaries, so 
 I would like to "install" mir-algorithm and similar libraries 
 for my rdmd scripts to use.


Sorry to reply to myself, but I found something that will run
the scripts, though it still doesn't make use of local libraries.


    /+ dub.sdl:
        dependency "mir-algorithm" version="~>1.0"
    +/

    import mir.ndslice
...

Since dub seems to work a bit better as the "interpreter" then
rdmd (assuming you're connected to the Internet) why is this not
promoted here:

https://tour.dlang.org/tour/en/welcome/run-d-program-locally

instead of rdmd?

Thanks,
Mar 16 2021
parent reply user1234 <user1234 12.de> writes:
On Wednesday, 17 March 2021 at 04:34:07 UTC, Chris Piker wrote:

 On Wednesday, 17 March 2021 at 03:43:22 UTC, Chris Piker wrote:


 Note: I'm aware of dub.  This isn't a question about dub.  I'm 
 making scripts for local use, not redistributable binaries, so 
 I would like to "install" mir-algorithm and similar libraries 
 for my rdmd scripts to use.


 Sorry to reply to myself, but I found something that will run
 the scripts, though it still doesn't make use of local 
 libraries.


    /+ dub.sdl:
        dependency "mir-algorithm" version="~>1.0"
    +/

    import mir.ndslice
 ...

 Since dub seems to work a bit better as the "interpreter" then
 rdmd (assuming you're connected to the Internet)


You can use local a specific local version too, for example the 
git repository


   /+ dub.sdl:
         dependency "mir-algorithm" 
path="/home/x/repositories/mir/mir-algorithm"
   +/

In addition with --nodeps, no internet is required.
Mar 16 2021
parent reply Chris Piker <chris hoopjump.com> writes:
On Wednesday, 17 March 2021 at 06:07:01 UTC, user1234 wrote:


 You can use local a specific local version too, for example the 
 git repository


   /+ dub.sdl:
         dependency "mir-algorithm" 
 path="/home/x/repositories/mir/mir-algorithm"
   +/

 In addition with --nodeps, no internet is required.


Very handy example.  Unfortunately it means that paths are 
embedded
in scripts, which is usually a bad idea.

I'm still looking for environment variables or config files that 
affect
dub's module include path.  Is there dub variable to give a 
general path
for all dependencies?  Since dub can read environment variables, 
this
may be a way to get a top-level module directory known to scripts 
without
hard coding paths.

Also, what do people do when generating .deb or .rpm packages for 
D
libraries?  They must reference some local library path in a 
general
fashion (I would think).

The only module paths I see referenced in:

   /etc/dmd.conf

are for phobos and the runtime import.  I guess I could just add 
another
one there.  Not sure if gdc also uses that file.
Mar 17 2021
next sibling parent user1234 <user1234 12.de> writes:
On Wednesday, 17 March 2021 at 07:13:31 UTC, Chris Piker wrote:

 On Wednesday, 17 March 2021 at 06:07:01 UTC, user1234 wrote:


 [...]


 Very handy example.  Unfortunately it means that paths are 
 embedded
 in scripts, which is usually a bad idea.

 [...]


You can use a local registry too. That should work but ten the 
dep version must be set to "*". See 
https://dub.pm/commandline.html#add-local
Mar 17 2021
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 17 March 2021 at 07:13:31 UTC, Chris Piker wrote:

 Very handy example.  Unfortunately it means that paths are 
 embedded
 in scripts, which is usually a bad idea.


The ability to use D source modules “script style” is something 
that has grown organically over time largely as a convenience. I 
doubt anyone is using it heavily enough to have tested the 
boundaries, In your exploration of those boundaries, please take 
note of what you discover so they can potentially be expanded 
where possible.
Mar 17 2021
parent reply Chris Piker <chris hoopjump.com> writes:
On Wednesday, 17 March 2021 at 09:34:21 UTC, Mike Parker wrote:

 On Wednesday, 17 March 2021 at 07:13:31 UTC, Chris Piker wrote:

 Very handy example.  Unfortunately it means that paths are 
 embedded
 in scripts, which is usually a bad idea.


 The ability to use D source modules “script style” is something 
 that has grown organically over time largely as a convenience. 
 I doubt anyone is using it heavily enough to have tested the 
 boundaries, In your exploration of those boundaries, please 
 take note of what you discover so they can potentially be 
 expanded where possible.


Sure will, thanks for the invite to contribute in a specific way.

D looks to be a good replacement for split Python/C development 
though I don't want to drag all my python baggage in here.  I'm 
trying to understand the D way of doing things before suggesting 
changes.

Interpreted languages like Python MATLAB, IDL are the norm in my 
field.  So anything that makes D easier to use for 
"quick-and-dirty" data analysis tasks would make it more 
palatable to the casual programmers I interact with.

I general dub seems fantastic!  I was stunned yesterday by a 
three-line vibe.d test script I ran that produced a compiled 
running web-server.

So, if I could do the equivalent of:

   dub add-path

via an environment variable (not a permanent change under 
~/.dub), or have some environment variable that tells dub where 
to read a "system-level" local-packages.json file and merge it's 
paths in with any personal settings, that would likely handle our 
internal code sharing needs.
Mar 17 2021
next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Wednesday, 17 March 2021 at 19:33:26 UTC, Chris Piker wrote:

 On Wednesday, 17 March 2021 at 09:34:21 UTC, Mike Parker wrote:

 [...]


 Sure will, thanks for the invite to contribute in a specific 
 way.

 [...]


You probably already know this, just sharing:

https://atilaoncode.blog/2020/02/19/want-to-call-c-from-python-use-d/
Mar 17 2021
parent Chris Piker <chris hoopjump.com> writes:
On Wednesday, 17 March 2021 at 20:13:49 UTC, Imperatorn wrote:

 On Wednesday, 17 March 2021 at 19:33:26 UTC, Chris Piker wrote:

 On Wednesday, 17 March 2021 at 09:34:21 UTC, Mike Parker wrote:

 [...]


 Sure will, thanks for the invite to contribute in a specific 
 way.

 [...]


 You probably already know this, just sharing:

 https://atilaoncode.blog/2020/02/19/want-to-call-c-from-python-use-d/


Hey, that looks nice.  I'm trying to get away from python as the
front end language, but I do have a fair bit of C code running 
around
and there are a lot of python users.

Thanks for the tip :)
Mar 17 2021
prev sibling parent reply Tobias Pankrath <tobias+dlang pankrath.net> writes:
On Wednesday, 17 March 2021 at 19:33:26 UTC, Chris Piker wrote:

 So, if I could do the equivalent of:

   dub add-path

 via an environment variable (not a permanent change under 
 ~/.dub), or have some environment variable that tells dub where 
 to read a "system-level" local-packages.json file and merge 
 it's paths in with any personal settings, that would likely 
 handle our internal code sharing needs.


For scripts this could be a good way, but it does not really work 
with
most dub packages:

1. put all your dependencies into a single location, like 
/home/<you>/dstuff
2. add -I /home/<you>/dstuff to your call to rdmd/dmd (or put 
into /etc/dmd.conf
3. add -i (lowercase) to your call of rdmd/dmd
4. profit

-i automatically adds all modules that are imported to the 
compilation, i.e. all your dependencies are compiled together 
with your code, when they are needed. It searches for them where 
-I points to.

To make this work the dependencies must have the correct project 
layout, e.g. sources should be in the top-level project directory 
and not in a subdirectory source. This rules out most dub 
packages :/
Mar 17 2021
parent Chris Piker <chris hoopjump.com> writes:
On Wednesday, 17 March 2021 at 20:24:19 UTC, Tobias Pankrath 
wrote:


 For scripts this could be a good way, but it does not really 
 work with most dub packages:

 1. put all your dependencies into a single location, like 
 /home/<you>/dstuff
 2. add -I /home/<you>/dstuff to your call to rdmd/dmd (or put 
 into /etc/dmd.conf
 3. add -i (lowercase) to your call of rdmd/dmd
 4. profit


I tried that route, and it's not too bad, but I have C library
dependencies so I start getting shebangs that look like this:


-L-ldas2.3 -L-lexpat -L-lssl -L-lfftw3

So kinda messy, though the rdmd -i option is nice.  Since the dub
packages have the linker info builtin, it seemed better to use 
this
instead:



and to assist with finding local packages, throw in some sort of
local search path via an environment variable reference in the
dub.sdl section.

If everyone used the same environment variable in dub.sdl comment
it could become a defacto standard for scripts, similar to
PYTHONPATH or MATLABPATH, though not nearly as fundamental.


 To make this work the dependencies must have the correct 
 project layout, e.g. sources should be in the top-level project 
 directory and not in a subdirectory source. This rules out most 
 dub packages :/


Yea, this seemed strange to me.  I'd think that a group would want
the compiler's module lookup semantics to match the common package
layout scheme and vice-versa.  But since I'm new around here I'll
just assume that the mismatch came about for a reason.  The dub
designers were probably trying to solve some problem that I'm 
unaware
of.
Mar 17 2021