Как избежать абсолютных путей в моем коде при использовании Git?

Question

До этого момента в моей карьере программирования я в основном работал над небольшими проектами, редактировал файлы PHP/Perl/Python непосредственно на хосте Linux dev, а затем копировал файлы в один и тот же каталог на реальном сервере, чтобы вставить их в производство.

Я пытаюсь настроить его, изучив, как использовать Git, а также как правильно написать код с Git в виду. Я хочу изучить лучшие практики для этого сценария:

Вот проект под названием «BigFun», в котором также используются некоторые библиотеки с задачами, которые являются общими для многих проектов.

/home/projects/BigFun/bin/script1.pl 
/home/projects/BigFun/bin/script2.pl 
/home/projects/BigFun/bin/script3.pl 
/home/projects/BigFun/lib/FunMaker.pm 

/home/projects/common/lib/Utilities.pm 
/home/projects/common/lib/Format.pm 

Если эта программа не управляется Git, и, если я знаю, что файлы не будут перемещены, я мог бы сделать что-то вроде этого:

#!/usr/bin/perl 
use warnings; 
use strict; 
use lib '/home/projects/BigFun/lib'; 
use FunMaker; 
use lib '/home/projects/common/lib'; 
use Utilities; 

Но как только это управляется Git , тогда любой сможет проверить эти файлы и поместить их в свое собственное пространство разработки. Жестко закодированные URL-адреса больше не будут работать, если ваш rootdir для разработки - «C: \ My Projects \ BigFun».

Так, некоторые вопросы:

1. я, вероятно, можно предположить, что «Lib» каталог BigFun всегда будет относительно каталога «Bin». Поэтому, возможно, я смогу изменить строку 3 на use lib '../lib';. Это правильное решение?

2. Похоже, однако, что этот пример кода я перечислил бы разделиться, чтобы два репозиториев - один для BigFun, а другой как «общий» репо, содержащий некоторые инструменты, которые используются многие проекты. Когда это произойдет, мне кажется, что код BigFun не сможет узнать, где найти «общие» библиотеки. /home/projects/common/lib отнюдь не гарантированно работает, и не будет ../../common/lib. Каков нормальный способ Git справиться с чем-то подобным?

Я работаю над книгой «Pro Git», но я еще не нашел ничего, чтобы ответить на эти вопросы. Спасибо всем, кто может указать мне в правильном направлении!

Answer 1

Ваш вопрос не о Git, это о сотрудничестве. Абсолютные пути заставляют всех пользователей вашей части программного обеспечения использовать один и тот же макет каталога, и это неприемлемо. Никакое достойное программное обеспечение не делает этого. Избегание абсолютных путей в программном обеспечении составляет норма, независимо от того, какую систему управления версиями вы используете или не используете.

Как заставить ваше программное обеспечение работать с использованием строго относительных путей и никогда не абсолютных путей? Это зависит от программного обеспечения/рамки/языка. Для относительных путей, чтобы иметь смысл, , вы должны рассмотреть вопрос: Относительно где? Вот некоторые идеи, как якоря, из которого можно было бы рассмотреть относительные пути:

• текущий рабочий каталог
• домашний каталог пользователя
• каталог установки пакета
• рамки каталог установки

На каждом языке обычно имеется механизм упаковки. Целью упаковки является то, что разработчики на языке могут создавать стандартный пакет, содержание которого организовано таким образом, что стандартные инструменты языка могут его установить, , добавляя программное обеспечение в общесистемные библиотеки язык, или в пользовательские библиотеки пользователей, или в указанную папку библиотеки. После установки программного обеспечения из стандартного пакета он будет готов к использованию, как и любое другое установленное программное обеспечение.

В вашем примере use warnings; и use strict; работают без какой-либо установки, так как эти библиотеки установлены в системе. Система находит свое местоположение относительно каталога установки Perl. Грубо говоря.

Так что вам нужно сделать, это:

1. Выяснить, как упаковать библиотеку Perl
2. Рисунок, как установить пакет PERL

После того как ваш установлены FunMaker и Utilities в качестве стандартных пакетов Perl вы сможете упростить свой сценарий как:

#!/usr/bin/perl 
use warnings; 
use strict; 
use FunMaker; 
use Utilities; 

Вам, разумеется, придется документировать зависимости сценария (FunMaker, Utilities), , а также как их установить (особенно в том месте, где будут размещаться эти пакеты).