On 2011-01-20 15:58, Adam Ruppe wrote:
When you compile, you have to provide a path anyhow, less hostile to
user and you don't have to change the code.
One of the things implicit in the thread now is removing the
need to provide a path - the compiler can (usually) figure it
out on its own. Try dmd -v and search for import lines.
But requiring it on the user side just makes sense if versioning
is important. Your program won't compile with a different version -
you aren't importing a generic thing, you're depending on something
specific. It should be explicit.
(Btw, this is the big failure of Linux dynamic libraries. They
started with a decent idea of having version numbers in the filename.
But then they ruined it by having generic symlinks that people can
use. They start using libwhatever.so when they really wanted
libwhatever.so.4.2. It's a symlink on their system, so Works for Me,
but if they give that binary to someone with a different symlink, it
won't work. Gah.)
This is where the "bundle" tool (often used together with rails) shines.
It's basically a dependency tool on top of rubygems which creates like a
bubble for your application.
* You specify, in a in a gemfile, all the package/libraries your
application depends on, if you want to can also specify a specific
version of a package.
* Then when you want to deploy your application (deploy your rails site
to the server) you lock the gemfile and it will create a new locked
gemfile. The locked gemfile specifies the exact version of all the
packages (even those you never specified a version for).
* Later on the server you run "bundle install" and it will use the
locked gemfile and it will install the exact same versions of the
packages you had on your developer machine.
--
/Jacob Carlborg
