Публикации с меткой «eclipse»

Посмотрел я на дерево жанров и оно мне не понравилось. Страшное, неудобное. И решил сразу заняться клиентской стороной. Тем более у нас есть отличнейший повод!

Итак, настроим gwt. Скачиваем eclipse 3.6 для java.
Далле переходим на страницы с загрузками GWT. Ставим gwt плагин для eclipse.

Создаем проект File > New > Web Application Project.

Название: genre
package: ru.musicmans

Запуск - Debug As > Web Application.

Переходим по адресу, устанавливаем плагин. Все работает.

Устанавливаем GWT Designer. Читаем quick start.

Далее можно конвертировать, созданный проект из gwt plugin (gwt plugin мы поставили потому, что в нем все равно находиться сам gwt) в gwt java project, который идет с дизайнером (правой кнопкой на проекте - convert to) или создать новый:



Сразу создадим модуль ru.musicmans.genre.GenreTree:



Итак, проект создан. Открываем genre.java и кликаем на вкладку Design.



Что нам надо для организации передачи данных? Мы не можем использовать rpc call gwt, так как у нас на стороне сервера django. Что делать в данном случае? Я рассматривал данный вопрос около года назад. Итог такой: возможен вывод данных в темплейте и преобразование их в javascript object, но это не очень оптимальный путь, тем более, что приложению обычно нужны данные в процессе работы (в том числе, обновленные). Поэтому лучшим решением мне предоставляется REST (с помощью этого подхода не надо проходить новый путь создания интерфейсов сервисов). Я решил не использовать SmartGWT, слишком он навороченный. В чистом GWT нет поддержки REST, поэтому воспользуемся Restlet Framework, ну а со стороны django - django-piston.

Скачаем Restlet Framework, Edition for Google Web Toolkit. Установим (укажем java build path в свойствах проекта).

Django-Piston

Теперь перейдем к серверной стороне. django-piston я уже как-то упоминал. Так вот, устанавливаем:

>c:\Python26\Scripts\pip.exe install hg+http://bitbucket.org/jespern/django-piston@c4b2d21db51a#egg=piston

Читаем документацию. Создадим приложение api, пропишем (r'^api/', include('api.urls')), в главном urls.py. Создадим в приложении файлы urls.py и handlers.py. Остальные файлы, кроме __init__.py можно удалить.
handlers.py:

from django.core.urlresolvers import reverse

from piston.handler import BaseHandler#@UnresolvedImport

from genre.models import GenreDirStyle#@UnresolvedImport

class GenreHandler(BaseHandler):
    allowed_methods = ('GET', )
    fields = ('name', 'type', 'url' )
    model = GenreDirStyle

    @classmethod
    def url(self, genre):
        return reverse('genre_genre', args=[genre.id])

    def read(self, request, genre_id):
        genre = GenreDirStyle.objects.get(id=int(genre_id))
        return genre

urls.py:

from django.conf.urls.defaults import *

from piston.resource import Resource#@UnresolvedImport

from api.handlers import GenreHandler#@UnresolvedImport

genre_resource = Resource(handler=GenreHandler)

urlpatterns = patterns('',
                        url(r'^genre/(?P[^/]+)/$', genre_resource, name='api_genre_id'), 
                        )

Переходим по адресу, например http://localhost:8000/api/genre/3/ :

{
    "url": "/genre/id/4/", 
    "type": 3, 
    "name": "Prog-Rock"
}

Чтобы открывать application/json в firefox, установите дополнение, а еще лучше используйте RESTClient для Firefox.

Вернемся к клиентской части.

Добавим widget дерево в gwt приложение tree:






Запускаем отладку, кстати, сразу рекомендую изменить параметр logLevel в конфигурации отладки.

С помощью firebug видим, что ответа на запрос по адресу http://localhost:8000/api/genre/3 не увенчались успехом, поэтому вспоминаем про проблему SOP.

В процессе поиска решений наткнулся на django-crossdomainxhr-middleware.py, позволяющее использовать кроссдоменные запросы (требуется firefox > 3.5).



Но мы пока его использовать не будем.

Итак, проблему SOP при разработке решим следующим образом. Отключим Jetty сервер, запускаемый в отладке, а также укажем порт 8000.


Сделаем символическую ссылку с директории war проекта на www\media\static\gwt\genre, под windows, например, так:

www\media\static\gwt>mklink /d genre d:\path\to\gwt\war\

Далее, можно отлаживать приложение по адресу примерно такому (предварительно запустив веб-сервер отладки django) http://localhost:8000/media/static/gwt/genre/GenreTree.html?gwt.codesvr=127.0.0.1:9997 адресу. Параметр gwt.codesvr обязателен при отладке gwt приложения.

А еще лучше создать темплейт django, подключив к нему приложение gwt примерно следующим образом. Создаем div с id='genreTreeEntryPointId' в темплейте, а в gwt root panel определяем следующим образом:
RootPanel rootPanel = RootPanel.get("genreTreeEntryPointId");

Теперь мы можем отлаживать gwt приложение прямо в "окружении" django-проекта, например, по адресу такому http://localhost:8000/genre/tree/?gwt.codesvr=127.0.0.1:9997&genre;_id=2 .

Серверный и клиентский код выкладывать слишком много, остановимся на нюансах:

- Выбор конкретного жанра в дереве (например при нажатии на меню жанров сверху). В этом случае загрузка списка для создания дерева вложенного множества осуществляется следующим образом (нам надо загрузить ветку, каждый элемент которой должен загрузить соседей):

        treeqs = GenreDirStyle.objects.raw("""SELECT t2.*
                    FROM genre_genredirstyle AS t1
                    LEFT JOIN genre_genredirstyle AS t2
                    ON t2.lft BETWEEN t1.lft AND t1.rgt
                    WHERE t1.lft <> %s AND t1.tree_id = 1 AND t2.depth-1 = t1.depth AND t2.tree_id = %s
                    ORDER BY t2.lft;""", (genre.lft, genre.rgt, genre.tree_id))

Построение дерева решил возложить на плечи клиентов.
- При загрузке приложения выводим div с изображением, который заменяется самим приложением, после его загрузки, а также выполнения всех ajax запросов.
- Настройки приложения выводим как JSON объект в javascript, получая значения которого в gwt приложении:

private final Dictionary paramsDict = Dictionary.getDictionary("gwtGenreParameters");
String paramsDict.get("API_GENRES_MAIN_URL");

- Автоматический разбор JSON ответа. Используем данное приложение.
Оно зависит от: google-gin и totoe (погуглите и подключайте в проект).
- Для обозначения состояния элемента дерева используем своей объект класса (сокращенный вид):

 private class GenreTreeItemData
 {
  private int id;
  private Boolean alreadyLoaded  = false;
  private String description;
  }

используя функцию setUserObject(Object).
- При создании проекта, в настройках gwt приложения наследуется стиль по умолчанию gwt standart. Так вот, проблема в том, что в нем есть правила css, переопределяющие наши (в том числе body). Решить это можно двумя способами, вот первый, а можно просто удалить нежелательные строки из standard.css файла в директории gwt\standard\ (их там немного и они вначале).
- Для генерации документации по API используем вид from piston.doc import documentation_view.

После работы все как обычно и результат:



ps. На стороне сервера попробовал использовать Aptana 3.0, там действительно отменная поддержка Django темплейтов в PyDev (но наткнулся на баг, ctrl+space вешает IDE, может только у меня так?).

Решил написать небольшой проект с использованием Pylons. Для тех, кто не знает, что это такое, могу сказать, что это один из самых мощных Python фреймворков. Он хранит себе лучшие идеи языков Perl, Ruby и Python и использовался в небезызвестных проектах DropBox, Digg, SourceForge и тд.
В качестве среды разработки я часто использую Eclipse. Но тут меня поджидали небольшие неудобства.

Подготовка Eclipse

1. Качаем Eclipse на машину разработчика (windows, linux).

2. В Eclipse - Help->Install New Software, выбираем из выпадающего списка Helios - http://download.eclipse.org/releases/helios, выбираем:
General Purpose Tools - Marketplace Client 1.0.0.v20100611-0430
Это новый удобный клиент репозитория приложений для Eclipse. Следует учесть, что в этом репозитории находятся и платные приложения, так что, проверяйте информацию нажатием на кнопочку "i". Почитать обзор.

3. Заходим в Help-Eclipse Marketplace, устанавливаем pydev (поддержка python).
4. Заходим в Help-Eclipse Marketplace, устанавливаем mylyn.

Почитать про Mylyn здесь и здесь.

5. Обеспечиваем синхронизацию задач mylyn в eclipse и redmine.

6. Заходим в Help-Eclipse Marketplace, устанавливаем Subversive (считайте меня консерватором) (после перезапуска устанавливаем коннектор SVN Kit последней версии).

7. Устанавливаем Aptana (Aptana Studio 3.0.0 Beta, 2я не установилась на Helios) (редактирование шаблонов html, css, может быть и js).
Update Site: http://download.aptana.com/studio3/plugin/install

Subversion

Будем использовать через svn+ssh://. Устанавливаем subversion и ssh на сервер для управления кодом.
#apt-get install subversion ssh

Создаем репозиторий:

root@codeserver:~# cd /
root@codeserver:/# mkdir repos
root@codeserver:/# cd repos/
root@codeserver:/repos# svnadmin create musicmans

Добавляем пользователя и устанавливаем владельца:

#useradd -m svnuser
#chown -R svnuser:svnuser /repos/musicmans/

Проверяем, что пользователь может логиниться по ssh.
Далее, в eclise на машине разработчика переходим в перспективу SVN Repository Exploring, в Repository Location, и добавляем New-Repository Location.

Указываем URL: svn+ssh://codeserver/repos/musicmans/, указываем логин, пароль, включаем Enable Struсture Detection, ну и смотрим другие параметры.

После успешного подключения создаем структуру репозитория в New -> Project Structure, Monolithic layout.

Создание проекта

Далее, нам надо создать каркас django проекта и выложить его в trunk.

Как установить python (2.6), django (1.2), рассказывать не буду, мануалов масса.

В новом pydev появилась замечательная вещь, как создание Django проекта из мастера создания проектов.

Переходим в перспективу Pydev, в контекстном меню package explorer указываем New - Project:



Далее, введем название проекта, директорию, а также необходимо настроить интерпретатор python, нажав на кнопку autoconfig:


Выбираем версию django. Выбираем Database Engine. От обещанного sqlite3 я отказался, решив использовать postgresql как в разработке, так и на рабочем сервере. Считаем что, postgresql установлен на машине разработчика (мануалов масса на любую систему).

После окончания работы мастера наблюдаем примерно такую картину:



Еще в pydev появилось вот такое меню для проекта:



Поменяем кодировку проекта на UTF-8, если необходимо (пункт меню Properties).

Далее, расшарим проект в репозиторий.

Subversive замечательно справляется со структурой trunk, branches, tags.

Сделаем так, что у нас проект будет находится в trunk под именем backend, то есть trunk/backend, ведь в будущем у нас может появиться и другие проекты, которые надо будет разместить в транке, например проект gwt.

В контекстном меню проекта указываем -> Team - Share Project, далее несколько окон по умолчанию, в окне указания расположения проекта:
use specified name: backend
Нажимаем далее, в комментарии видим что-то похожее:
Share project "musicmans" into "svn+ssh://codeserver/repos/musicmans"
И коммитим изменения, в окне с коммитом необходимо добавить *.setting, *.pydevproject и *.project в svn:ignore (контекстное меню в списке ресурсов).
Перейдем в SVN Repository Exploring, в Repository Location нажмем на кнопку обновить:



Предварительную настройку директорий и проекта выполнем в транке, а конкретные задачи создав ветку и переключившись в нее. Смотрите, как это просто делается в subversive:





Создаем и сразу переключаемся в ветку. Пока делать этого не будем. На этом настройка Eclipse пока закончена.

Уважаемое Хабрсообщество и все интересующиеся языком программирования Python. Я начал переводить весьма интересную книгу Gray Hat Python. Правда, пока я перевел лишь предисловие и первую главу. Начал переводить для себя (поэтому немного коряво), но все таки решил, что нужно делиться. :)

И так предоставим слово автору.

Вся работа в GWT имеет подробную документацию. В ней все понятно и прозрачно. Но наше дело тормозится тем, что в качестве бекенда у нас выступает Django. То есть стандартный GWT RPC нам не подходит. Встает вопрос о том, как обмениваться данными между GWT и Django.

Я долго раздумывал, какой интерфейс взаимодействия выбрать. Технология-то одна - ajax, а вот какой инструмент более удобен? Можно попробовать использовать RequestBuilder, но этот метод не совсем удобен и не совсем универсален. Поэтому я выбрал json-rpc. Для него уже все создано, как на стороне django, так и на стороне GWT.

Json-rpc, это легкий протокол удаленного вызова процедур, использующий для своего функционирования формат Json.
Пример запроса и ответа:

--> { "method": "echo", "params": ["Hello JSON-RPC"], "id": 1}

<-- />

Начнем с django. Добавляем поддержку json-rpc в наш проект.

Импортируем django-json-rpc и добавляем точку входа в urls.py.

 

from jsonrpc import jsonrpc_site

import myproj.myapp.views # подключаем файл, в котором буду храниться rpc функции



urlpatterns += patterns('', 

   url(r'^json/', jsonrpc_site.dispatch, name="jsonrpc_mountpoint"),

)

Возьмем пример с readme:

 

from jsonrpc import jsonrpc_method



@jsonrpc_method('myapp.sayHello')

def whats_the_time(request, name='Lester'):

  return "Hello %s" % name

Запускаем сервер, запускаем шел django

 

 ./manage.py runserver 8080

 ./manage.py shell

И тестируем:

 

>>> from jsonrpc.proxy import ServiceProxy

>>> s = ServiceProxy('http://localhost:8080/json/')

>>> s.myapp.sayHello('Sam')

{u'error': None, u'id': u'jsonrpc', u'result': u'Hello Sam'}

В общем, в документе все написано. Также в приложении есть своей браузер, зайти на него можно по адресу http://localhost:8080/json/browse/ , добавив в urls.py, например так:

 

if settings.DEBUG:

    urlpatterns += patterns('',

              url(r'^json/browse/', 'jsonrpc.views.browse', name="jsonrpc_browser"), # for the graphical browser/web console only, omissible

    )



urlpatterns += patterns('', 

   url(r'^json/', jsonrpc_site.dispatch, name="jsonrpc_mountpoint"),

)

Я нашел несколько неточностей в документации, так, там name="jsonrpc_browser" без буквы "r" на конце, плюс url браузера
идет после r'^json/', который перекрывает его вызов.

Итак, rpc в django у нас теперь есть. Переходим к клиентской части rpc в gwt.

Проделываем все операции, указанные в readme и... у меня не заработало.

 

09:36:42.942 [ERROR] [myapp] Errors in 'jar:file:/lovely.gwt.jsonrpc-0.7.jar!/lovely/gwt/jsonrpc/client/JSONServiceBase.java'

09:36:42.957 [ERROR] [myapp] Line 29: The type JSONServiceBase must implement the inherited abstract method ServiceDefTarget.setRpcRequestBuilder(RpcRequestBuilder)

Судя по всему, в GWT 2.0 изменились какие-то механизмы в сервисах JSON. Наверное класс JSONServiceBase раньше не требовал реализации метода ServiceDefTarget.setRpcRequestBuilder.
Что ж, давайте взглянем на исходники.
Действительно, функции setRpcRequestBuilder нет.

Проект не обновляется, разбираться времени нет, так что пробуем еще один вариант gwt-json-rpc.
По инструкции подключаем библиотеку. В инструкции написано что библиотека использует свой JSON кодер/декодер, поэтому можно использовать простые типы java: String, int, boolean, Array, HashMap, ArrayList, Vector, вместо классов GWT. В общем, она даже проще, чем lovely-gwt-jsonrpc.
У меня получился следующий код.

 

//Create a new JsonRpc instance

JsonRpc jsonRpc = new JsonRpc();



//Create a callback handler

AsyncCallback callback = new AsyncCallback() {



		  public void onFailure(Throwable caught) {

			  SC.say(caught.toString());

		  };



		  public void onSuccess(Object result) {

			  SC.say(result.toString());

		  };

		};

jsonRpc.request(

		  "http://localhost:8080/json/",

		  "myapp.sayHello", 

		  null,

		  callback);

Что такое SC смотрим здесь.

После запуска мы обнаруживаем, что все результаты попыток вызова функции попадают в onFailure. Обусловлено это скорее всего тем, что сервер Django и сервер gwt находятся на разных портах, а это противоречит Same Origin Policy.
Далее, я скомпилировал проект, чтобы скопировать его в статический путь в проекте Django, и запустить под сервером Django, чтобы не нарушать SOP. И обнаружил, что CsrfMiddleware не дает скомпилированному gwt приложению делать POST запросы. Но мы знаем, что фрейморки, вроде jQuery позволяли это с легкостью делать. А все потому, что gwt-json-rpc при создании RequestBuilder не создает заголовок вида "X-Requested-With: XMLHttpRequest", поэтому django (точнее middleware) считает, что запрос сделан с другого домена, и возвращает ошибку 403. Значит надо сообщить ему об этом. AJAX запросы считаются безопасными и не нуждаются в проверке, так как современные браузеры придерживаются SOP. Придется добавить данный заголовок в код библиотеки и пересобрать ее. Разработчику проблему описал. Может быть на момент прочтения статьи в ней будет прописан данный заголовок (функция JsonRpc.request):

builder.setHeader("X-Requested-With", "XMLHttpRequest");

Я его добавил сам и сделал новый jar. Компилируем проект, копируем в путь для статики в django, и проверяем - все должно работать.
Остался один ньюанс - работа в дебаг режиме и ajax запросы. Не будем же мы каждый раз компилировать проект, тем более терять все прелести дебага. Воспользуемся HTTP proxy servlet.
Качаем сервлет, копируем в папку WEB-INF/lib, правим web.xml, у меня примерно следующее:

  HttpProxy

  com.jsos.httpproxy.HttpProxyServlet



  host

  http://localhost:8080/json/







 

  HttpProxy

  /json/

 

Меняем путь запроса:

jsonRpc.request(

		"/json/",

		"myapp.sayHello", 

		null,

		 callback);

и проверяем работу в дебаг режиме.

Вот и все. Удачной разработки.

При работе Eclipse+Django(как начать работать было описано в статье Интелисенс Eclipse в Django проектах) я столкнулся с проблемой в том, что при изменении файла настроек приходилось перезапускать сервер для применения изменений.

В тот момент я не придал этому особого значение, для меня это было не принципиально, но вот в очередной раз, при просмотре ссылок на мой блог, наткнулся на тему в форуме "Возникли проблемы следующего характера - когда я вношу изменения в settings.py то консоль в этих редакторах не перезагружаются".

Больше всего возмутила не сама проблема, а бестолковые ответы, это и дало неплохой стимул для поиска решений. Через 30 минут я наткнулся на одно интересное решение "How to debug django web application with autoreload.", которое было основано на возможности удаленной отладки PyDev. Комментарий добавил в форум, а сейчас хотел бы написать о полном цикле решения этой проблемы, про это и пойдет дальше речь.

1. Плагин PyDev

Если вы пользуетесь плагином PyDev до версии 1.5, то вам необходимо будет установить дополнительно решение PyDev extension, полный список версий можно найти в следующих архивах.

Я бы порекомендовал установить версию 1.5 или выше, так как с этой версии данный проект перешел в open source и PyDev extension интегрирован в PyDev. Если вы решили установить новую версию, то сначала удалите старую(Меню "Help"->"Software Updates...", вкладка "Installed Software", выбрать плагин, нажать кнопку "Uninstall..."), дальше устанавливаем новый плагин. Новую версию плагина можно скачать с сайта SourgeForce или настроить автообновление в Eclipse - http://pydev.org/updates.

2. Подключение pydevd.py

Для установки точек прерывания к проекту необходимо подключить исходники модуля pydevd, который находится в плагине PyDev. Для моей версии его можно найти по следующему пути: e:\Eclipse\plugins\org.python.pydev.debug_1.5.0.1251989166\pysrc\pydevd.py

Подключить папку с этим фалом можно двумя способами:

1. Подключение папки в проекте. Для этого нужно вызвать контекстное меню проекта, меню "Properties", закладка "PyDev - PYTHONPATH", таб "External Libraries" и с помощью кнопки "Add source folder" прописать путь.



2. Подключение папки в настройках плагина PyDev. Для этого нужно вызвать меню "Window"->"Preferences"->"PyDev"->"Interpreter Python", таб "Libraries" и с помощью кнопки "New Folder" добавить путь к файлу.



После этих манипуляций у вас в проекте будет доступен модуль pydevd. При работаете с несколькими проектами, если вы воспользуетесь первым вариантом, то вам необходимо будет выполнить такие действия для каждого проекта, если вторым, то будет достаточно выполнить настройки для каждого экземпляра Eclipse.

3. Запуск PyDev server

Для удаленной отладки вам понадобится запустить PeDev server. В версиях PeDev до 1.5 он был доступен только c PyDev extension, в версии 1.5 и выше - доступен непосредственно в плагине PyDev. Иконку запуска сервера можно найти только в Debug перспективе, поэтому входим в данную перспективу и находим иконку "PyDev:Start PyDev Server", нажимаем ее для запуска.





После запуска в консоли у вас появится следующие сообщение:

4. Установка точек остановки

Для установки точки прерывания нужно прописать следующий код:

import pydevd;pydevd.settrace();

Данное решение не очень практичное, поэтому воспользуемся решением от bear330. Для этого файл manage.py изменим следующим образом:

from django.core.management import execute_manager
import sys
try:
    import settings # Assumed to be in the same directory.
except ImportError:
    sys.stderr.write("Error: Can't find the file 'settings.py' in the directory containing %r. It appears you've customized things.\nYou'll have to run django-admin.py, passing it your settings module.\n(If the file settings.py does indeed exist, it's causing an ImportError somehow.)\n" % __file__)
    sys.exit(1) 

#Magic by bear330. http://bear330.wordpress.com/2007/10/30/how-to-debug-django-web-application-with-autoreload/
if len(sys.argv) > 1:
    command = sys.argv[1]
if settings.DEBUG and (command == "runserver" or command == "testserver"):
    # Make pydev debugger works for auto reload.
    try:
        import pydevd
    except ImportError:
        sys.stderr.write("Error: " +
            "You must add org.python.pydev.debug.pysrc to your PYTHONPATH.")
        sys.exit(1)

    from django.utils import autoreload
    m = autoreload.main
    def main(main_func, args=None, kwargs=None):
        import os
        if os.environ.get("RUN_MAIN") == "true":
            def pydevdDecorator(func):
                def wrap(*args, **kws):
                    pydevd.settrace(suspend=False)
                    return func(*args, **kws)
                return wrap
            main_func = pydevdDecorator(main_func)
        return m(main_func, args, kwargs)

    autoreload.main = main
    
if __name__ == "__main__":
    execute_manager(settings)

И в нужном месте установим точку остановки.

Запускаем сервер Django через Eclipse

На последнем шаге необходимо запустить сервер Django через Eclipse. Для этого входим в меню "Run"->"Run Configurations"->"Python run", вызвав контекстное меню на этом пункте, создаем новую конфигурацию. В табе "Main" для поля "Project" указываем свой проект, "Main module" устанавливаем в "manage.py". В табе "Arguments" для поля "Program arguments" задаем "runserver 8080".





Жмем "Run" и наслаждаемся отладкой. Необходимо некоторое время, чтобы PeDev server подсоединился к потоку Django server-а, у меня это происходит примерно за 7 сек.



Не обошлось без ложки дегтя, в некоторых ситуациях перестают отрабатывать точки остановки :(. Решение оказалось очень простым, добавляем пробел и сохраняем файл. Происходит рестарт Django сервера и PyDev сервер снова автоматически подхватывает поток, все отлично начинает работать.

При работе Eclipse+Django(как начать работать было описано в статье Интелисенс Eclipse в Django проектах) я столкнулся с проблемой в том, что при изменении файла настроек приходилось перезапускать сервер для применения изменений.

В тот момент я не придал этому особого значение, для меня это было не принципиально, но вот в очередной раз, при просмотре ссылок на мой блог, наткнулся на тему в форуме "Возникли проблемы следующего характера - когда я вношу изменения в settings.py то консоль в этих редакторах не перезагружаются".

Больше всего возмутила не сама проблема, а бестолковые ответы, это и дало неплохой стимул для поиска решений. Через 30 минут я наткнулся на одно интересное решение "How to debug django web application with autoreload.", которое было основано на возможности удаленной отладки PyDev. Комментарий добавил в форум, а сейчас хотел бы написать о полном цикле решения этой проблемы, про это и пойдет дальше речь.

1. Плагин PyDev

Если вы пользуетесь плагином PyDev до версии 1.5, то вам необходимо будет установить дополнительно решение PyDev extension, полный список версий можно найти в следующих архивах.

Я бы порекомендовал установить версию 1.5 или выше, так как с этой версии данный проект перешел в open source и PyDev extension интегрирован в PyDev. Если вы решили установить новую версию, то сначала удалите старую(Меню "Help"->"Software Updates...", вкладка "Installed Software", выбрать плагин, нажать кнопку "Uninstall..."), дальше устанавливаем новый плагин. Новую версию плагина можно скачать с сайта SourgeForce или настроить автообновление в Eclipse - http://pydev.org/updates.

2. Подключение pydevd.py

Для установки точек прерывания к проекту необходимо подключить исходники модуля pydevd, который находится в плагине PyDev. Для моей версии его можно найти по следующему пути: e:\Eclipse\plugins\org.python.pydev.debug_1.5.0.1251989166\pysrc\pydevd.py

Подключить папку с этим фалом можно двумя способами:

1. Подключение папки в проекте. Для этого нужно вызвать контекстное меню проекта, меню "Properties", закладка "PyDev - PYTHONPATH", таб "External Libraries" и с помощью кнопки "Add source folder" прописать путь.



2. Подключение папки в настройках плагина PyDev. Для этого нужно вызвать меню "Window"->"Preferences"->"PyDev"->"Interpreter Python", таб "Libraries" и с помощью кнопки "New Folder" добавить путь к файлу.



После этих манипуляций у вас в проекте будет доступен модуль pydevd. При работаете с несколькими проектами, если вы воспользуетесь первым вариантом, то вам необходимо будет выполнить такие действия для каждого проекта, если вторым, то будет достаточно выполнить настройки для каждого экземпляра Eclipse.

3. Запуск PyDev server

Для удаленной отладки вам понадобится запустить PeDev server. В версиях PeDev до 1.5 он был доступен только c PyDev extension, в версии 1.5 и выше - доступен непосредственно в плагине PyDev. Иконку запуска сервера можно найти только в Debug перспективе, поэтому входим в данную перспективу и находим иконку "PyDev:Start PyDev Server", нажимаем ее для запуска.





После запуска в консоли у вас появится следующие сообщение:

4. Установка точек остановки

Для установки точки прерывания нужно прописать следующий код:

import pydevd;pydevd.settrace();

Данное решение не очень практичное, поэтому воспользуемся решением от bear330. Для этого файл manage.py изменим следующим образом:

from django.core.management import execute_manager
import sys
try:
    import settings # Assumed to be in the same directory.
except ImportError:
    sys.stderr.write("Error: Can't find the file 'settings.py' in the directory containing %r. It appears you've customized things.\nYou'll have to run django-admin.py, passing it your settings module.\n(If the file settings.py does indeed exist, it's causing an ImportError somehow.)\n" % __file__)
    sys.exit(1) 

#Magic by bear330. http://bear330.wordpress.com/2007/10/30/how-to-debug-django-web-application-with-autoreload/
if len(sys.argv) > 1:
    command = sys.argv[1]
if settings.DEBUG and (command == "runserver" or command == "testserver"):
    # Make pydev debugger works for auto reload.
    try:
        import pydevd
    except ImportError:
        sys.stderr.write("Error: " +
            "You must add org.python.pydev.debug.pysrc to your PYTHONPATH.")
        sys.exit(1)

    from django.utils import autoreload
    m = autoreload.main
    def main(main_func, args=None, kwargs=None):
        import os
        if os.environ.get("RUN_MAIN") == "true":
            def pydevdDecorator(func):
                def wrap(*args, **kws):
                    pydevd.settrace(suspend=False)
                    return func(*args, **kws)
                return wrap
            main_func = pydevdDecorator(main_func)
        return m(main_func, args, kwargs)

    autoreload.main = main
    
if __name__ == "__main__":
    execute_manager(settings)

И в нужном месте установим точку остановки.

Запускаем сервер Django через Eclipse

На последнем шаге необходимо запустить сервер Django через Eclipse. Для этого входим в меню "Run"->"Run Configurations"->"Python run", вызвав контекстное меню на этом пункте, создаем новую конфигурацию. В табе "Main" для поля "Project" указываем свой проект, "Main module" устанавливаем в "manage.py". В табе "Arguments" для поля "Program arguments" задаем "runserver 8080".





Жмем "Run" и наслаждаемся отладкой. Необходимо некоторое время, чтобы PeDev server подсоединился к потоку Django server-а, у меня это происходит примерно за 7 сек.



Не обошлось без ложки дегтя, в некоторых ситуациях перестают отрабатывать точки остановки :(. Решение оказалось очень простым, добавляем пробел и сохраняем файл. Происходит рестарт Django сервера и PyDev сервер снова автоматически подхватывает поток, все отлично начинает работать.

Pydev в сентябре переехал. Да еще его расширения стали Open Source:

Pydev Extensions is now merged with Pydev, and its once closed source code has become open source. Thus, there is no more Pydev Extensions, only the open source Pydev, with all the capabilities of Pydev Extensions incorporated.

Изменился и сайт апдейта для eclipse - http://pydev.org/updates .

А что нам это дает? А это нам дает бесплатную штуку под названием "Debug 'server' for remote debugging", с помощью которой можно дебажить django очень удобным способом.

Для начала выполняем условия, как написано здесь, в том числе заносим в PYTHONPATH в настройках Eclipse путь примерно следующего содержания
"eclipse\plugins\org.python.pydev.debug_1.5.0.1251989166\pysrc\" (найдете у себя подобный) и запускаем сервер (из перспективы debug):



Добавляем следующий код в manage.py (после if __name__ == "__main__":) проекта, что дает нам возможность обернуть PyDev брейкпоинты в pydevd.settrace(), который пересылает трейс Debug Remote серверу (для теста рекомендую сначала использовать --noreload и pydevd.settrace(), и убедиться, что трейс возникает именно на Debug Remote server, так же можно попробовать запускать проект не в режиме дебага, а в режиме run, трейс должен отправляться в любом режиме):

import sys

if len(sys.argv) > 1:
    command = sys.argv[1]
if settings.DEBUG and (command == "runserver" or command == "testserver"):
    # Make pydev debugger works for auto reload.
    try:
        import pydevd
    except ImportError:
        sys.stderr.write("Error: " +
            "You must add org.python.pydev.debug.pysrc to your PYTHONPATH.")
        sys.exit(1)

    from django.utils import autoreload
    m = autoreload.main
    def main(main_func, args=None, kwargs=None):
        import os
        if os.environ.get("RUN_MAIN") == "true":
            def pydevdDecorator(func):
                def wrap(*args, **kws):
                    pydevd.settrace(suspend=False)
                    return func(*args, **kws)
                return wrap
            main_func = pydevdDecorator(main_func)

        return m(main_func, args, kwargs)

     autoreload.main = main

А для чего мы это, собственно говоря, делали? А чтобы запускать runserver без --noreload. Чтобы и изменение кода и брейкпоинты обрабатывались "онлайн".
Примерно вот такая картина:

Pydev в сентябре переехал. Да еще его расширения стали Open Source:

Pydev Extensions is now merged with Pydev, and its once closed source code has become open source. Thus, there is no more Pydev Extensions, only the open source Pydev, with all the capabilities of Pydev Extensions incorporated.

Изменился и сайт апдейта для eclipse - http://pydev.org/updates .

А что нам это дает? А это нам дает бесплатную штуку под названием "Debug 'server' for remote debugging", с помощью которой можно дебажить django очень удобным способом.

Для начала выполняем условия, как написано здесь, в том числе заносим в PYTHONPATH в настройках Eclipse путь примерно следующего содержания
"eclipse\plugins\org.python.pydev.debug_1.5.0.1251989166\pysrc\" (найдете у себя подобный) и запускаем сервер (из перспективы debug):



Добавляем следующий код в manage.py (после if __name__ == "__main__":) проекта, что дает нам возможность обернуть PyDev брейкпоинты в pydevd.settrace(), который пересылает трейс Debug Remote серверу (для теста рекомендую сначала использовать --noreload и pydevd.settrace(), и убедиться, что трейс возникает именно на Debug Remote server, так же можно попробовать запускать проект не в режиме дебага, а в режиме run, трейс должен отправляться в любом режиме):

import sys

if len(sys.argv) > 1:
    command = sys.argv[1]
if settings.DEBUG and (command == "runserver" or command == "testserver"):
    # Make pydev debugger works for auto reload.
    try:
        import pydevd
    except ImportError:
        sys.stderr.write("Error: " +
            "You must add org.python.pydev.debug.pysrc to your PYTHONPATH.")
        sys.exit(1)

    from django.utils import autoreload
    m = autoreload.main
    def main(main_func, args=None, kwargs=None):
        import os
        if os.environ.get("RUN_MAIN") == "true":
            def pydevdDecorator(func):
                def wrap(*args, **kws):
                    pydevd.settrace(suspend=False)
                    return func(*args, **kws)
                return wrap
            main_func = pydevdDecorator(main_func)

        return m(main_func, args, kwargs)

     autoreload.main = main

А для чего мы это, собственно говоря, делали? А чтобы запускать runserver без --noreload. Чтобы и изменение кода и брейкпоинты обрабатывались "онлайн".
Примерно вот такая картина:

Тестирование в Django очень хорошо продумано, и при дальнейшей разработке позволяет быстро выявлять ошибки. После рефакторинга, проверив тесты, вы получаете уверенность и облегчение в том, что не возникло каких то ошибок, ну это при условии того, что у вас покрыт весь код тестами :).

Вы можете писать как Doctest, так и Unit test. Подробности того, как писать тесты, какие части приложения необходимо тестировать и т.д. очень хорошо раскрыты на сайте проекта Django.

Если вас интересует как начать работать с Django+Eclipse, то прочитайте мою предыдущую статью о "Интелисенс Eclipse в Django проектах", в ней найдете описание того, что нужно сделать и какие проблемы возникают в начале работы.

И вот вы уже написали в каждом app тесты, поместив их или в файл tests.py или models.py. Что делать дальше?

Шаг 1. Настройка тестирования

Для настройки тестирования необходимо перейти в проект и в окне "Package Explorer" вызвать контекстное меню(щелчок правой кнопкой мыши), выбрать пункт "Run As"->"Run Configurtions...".



В возникшем окне добавляем новую настройку запуска в категории "Python Run", для этого выберем эту категорию и, вызвав контекстное меню, выбираем пункт "New". Созданную настройку запуска заполняем следующим образом:

1. Таб Main
Тут необходимо выбрать ваш проект, и модуль для запуска. У меня проект называется "ftd", вот он и выбран в поле "Project". "Main Module" устанавливаем наш файл manage.py (лучше это делать воспользовавшись кнопкой Browse), для моего проекта оно стало установлено в "${workspace_loc:ftd/manage.py}"



2. Таб Arguments
В данной вкладке добавляем параметры для запуска, а именно "test --verbosity=2". "test" означает, что нам необходимо запустить тестирование, а параметр "verbosity" указывает на уровень вывода детализации сообщений при тестировании.



3. Таб Environment
На этой вкладке вы можете настроить переменные окружения. Для запуска нам нужно указать, какой файл настроек использовать. Добавляем новую с параметрами "Name"="DJANGO_SETTINGS_MODULE", "Value"="setting.py".



Жмем "Run" и наблюдаем за результатом!

Оптимизация времени тестирование

При использовании 'postgresql', 'mysql', 'oracle' провайдеров данных вы получаете большие задержки в тестировании из-за того, что много времени уходить на создание таблиц и на построение индексов. Исправить данную ситуацию можно воспользовавшись провайдером 'sqlite3'.

Для этого создадим файл с настройками для тестирования settings_test.py

from settings import *

DATABASE_ENGINE = 'sqlite3'
DATABASE_NAME = ':memory:'
DATABASE_USER = ''
DATABASE_PASSWORD = ''
DATABASE_HOST = ''
DATABASE_PORT = ''

И пропишем его в переменных окружения запуска. "Name"="DJANGO_SETTINGS_MODULE", "Value"="settings_test.py".



Теперь запуск тестов уже занимает меньше времени.

fixtures в тестировании

Если у вас в app определена папка fixtures, в которой будут лежать файл "initial_data.json" или "initial_data.xml" с данными, которые необходимы для старта приложения, то такие данные при старте тестов будут загружены автоматически.

Например:

app
|-fixtures
      |-initial_data.json
      |-test_data.json
|-__init__.py
|-models.py
|-tests.py
|-urls.py
|-views.py

Так же вы в конкретном модуле тестирования можете указать загрузку данных с файлов fixture.

from django.test import TestCase
from django.test.client import Client

class MyTest(TestCase):
    fixtures = ['test_data.json']

Тестирование в Django очень хорошо продумано, и при дальнейшей разработке позволяет быстро выявлять ошибки. После рефакторинга, проверив тесты, вы получаете уверенность и облегчение в том, что не возникло каких то ошибок, ну это при условии того, что у вас покрыт весь код тестами :).

Вы можете писать как Doctest, так и Unit test. Подробности того, как писать тесты, какие части приложения необходимо тестировать и т.д. очень хорошо раскрыты на сайте проекта Django.

Если вас интересует как начать работать с Django+Eclipse, то прочитайте мою предыдущую статью о "Интелисенс Eclipse в Django проектах", в ней найдете описание того, что нужно сделать и какие проблемы возникают в начале работы.

И вот вы уже написали в каждом app тесты, поместив их или в файл tests.py или models.py. Что делать дальше?

Шаг 1. Настройка тестирования

Для настройки тестирования необходимо перейти в проект и в окне "Package Explorer" вызвать контекстное меню(щелчок правой кнопкой мыши), выбрать пункт "Run As"->"Run Configurtions...".



В возникшем окне добавляем новую настройку запуска в категории "Python Run", для этого выберем эту категорию и, вызвав контекстное меню, выбираем пункт "New". Созданную настройку запуска заполняем следующим образом:

1. Таб Main
Тут необходимо выбрать ваш проект, и модуль для запуска. У меня проект называется "ftd", вот он и выбран в поле "Project". "Main Module" устанавливаем наш файл manage.py (лучше это делать воспользовавшись кнопкой Browse), для моего проекта оно стало установлено в "${workspace_loc:ftd/manage.py}"



2. Таб Arguments
В данной вкладке добавляем параметры для запуска, а именно "test --verbosity=2". "test" означает, что нам необходимо запустить тестирование, а параметр "verbosity" указывает на уровень вывода детализации сообщений при тестировании.



3. Таб Environment
На этой вкладке вы можете настроить переменные окружения. Для запуска нам нужно указать, какой файл настроек использовать. Добавляем новую с параметрами "Name"="DJANGO_SETTINGS_MODULE", "Value"="setting.py".



Жмем "Run" и наблюдаем за результатом!

Оптимизация времени тестирование

При использовании 'postgresql', 'mysql', 'oracle' провайдеров данных вы получаете большие задержки в тестировании из-за того, что много времени уходить на создание таблиц и на построение индексов. Исправить данную ситуацию можно воспользовавшись провайдером 'sqlite3'.

Для этого создадим файл с настройками для тестирования settings_test.py

from settings import *

DATABASE_ENGINE = 'sqlite3'
DATABASE_NAME = ':memory:'
DATABASE_USER = ''
DATABASE_PASSWORD = ''
DATABASE_HOST = ''
DATABASE_PORT = ''

И пропишем его в переменных окружения запуска. "Name"="DJANGO_SETTINGS_MODULE", "Value"="settings_test.py".



Теперь запуск тестов уже занимает меньше времени.

fixtures в тестировании

Если у вас в app определена папка fixtures, в которой будут лежать файл "initial_data.json" или "initial_data.xml" с данными, которые необходимы для старта приложения, то такие данные при старте тестов будут загружены автоматически.

Например:

app
|-fixtures
      |-initial_data.json
      |-test_data.json
|-__init__.py
|-models.py
|-tests.py
|-urls.py
|-views.py

Так же вы в конкретном модуле тестирования можете указать загрузку данных с файлов fixture.

from django.test import TestCase
from django.test.client import Client

class MyTest(TestCase):
    fixtures = ['test_data.json']

При написании кода на любом языке всегда важна скорость и отсутствие ошибок. Если вы гуру, печатаете 600 символов в минуту, "до символа" запоминаете названия всех API классов и методов с которым работаете и пишете без опечаток, то вам не нужна эта статья :).

Что позволяет писать быстрее? Посредством чего можно увидеть ошибки еще до момента запуска?

По моему мнению один из ключевых моментов в проектировании является IDE. Когда я только начал изучат Django, то сперва обучался по книге, а в качестве редактора использовал обычный notepad и Python GUI. Язык и фреймворк вызвал у меня большой интерес, сам по себе язык был очень гибким и выходил за рамки моего предыдущего 4-х летнего опыта на .NET. Хотя сам язык очень динамичный и что угодно можно присвоить куда угодно, но больше всего меня "убивало" отсутствие нормальной проверки синтаксиса и интелисенса.

При поиске удобного IDE для проектирования я остановил на Eclipse(Если кто то считает что есть что-то лучше для Django, то сообщите мне). Под него есть много разнообразных плагинов, а главное можно легко переключится на разработку на Java, Flex и т.д.

Для работы с python в Eclipse вам необходимо будет установить плагин PyDev. Вы будете приятно удивлены но 3 сентября Aptana выпустила новую версию PyDev 1.5.0 которая стала доступна с открытыми исходными кодами. Последнюю версию можно скачать с официального сайта продукта, версия на github будет закрыта. Пример установки.

Но спустя довольно таки короткое время данное расширение меня разочаровало :(. Оно лишь было необходимо для интеграции python и eclipse, позволяло запустить IDE в режиме работы и отладки, a самое главного то и небыло. В поисках "галактической справедливости" я наткнулся на Aptana Studio(Aptana разработчики PyDev). Не долго думая установил и сразу выросли крылья. При установке у вас появляется нормальный интелисенс, чего и не хватало так. Скачать ее можно вот тут, мануал по установке тут.

Правда и в ней не обошлось без "подводных камней"

Порт 8000

Первый раз запускаем с настройкой через Run -> Run configurations, выбрав Python Run добавляем параметры: "Main Module" на файл manage.py, а в параметр "Arguments" передаем "runserver --noreload", применяем и запускаем. Казалось бы все просто, но при запуске возникает ошибка "Error: [Errno 10013]". Оказывается Aptana Studio при установке резервирует порт 8000 под свои нужны. Вносим коррективы ("runserver 8080 --noreload") и наслаждаемся функционалом. С такими же настройками можно запустить и в Debug режиме.

Модули не на корневом уровне

Если вы в проекте выделяете подпапки для app, библиотек и т.д., то интелисенс по таким директориям будет работать только с указанием проекта, что не приемлемо, так как не позволит использовать данный код повторно в других проектах.
root project
|-libs
| |-mylib.py
|-app
| |-myapp
| | |-view.py

view.py

import mylib

В этом случае необходимо добавить эти папки в исходные папки проекта. Для этого зайдите в свойство проекта, пункт "PyDev - PYTHONPATH" и на вкладке "Source Folders" необходимо добавить необходимые папки через "Add source folder".

После всех этих манипуляция у вас появится нормальный интелисенс в проектах Django. Судя по себе скорость разработки вырастает где то на 15%-20%, а удовлетворенность на 100%!

Вышла новая версия PyDev, плагина к Eclipse, позволяющего разрабатывать проекты на Питоне. В новой версии разработчик Fabio Zadrozny решил интегрировать в бесплатную открытую версию всю функциональность платного дополнения PyDev Extensions.

В новой версии:

• Продвинутая интерактивная консоль с авто-импортом,
• Анализ качества кода в реальном времени,
• Контекстно-независимое code-completion с авто-импортом,
• Иерархическая диаграмма классов,
• Консоль отладки с возможностью запуска удаленного дебаг-сервера.

Подробную информацию можно узнать на официальном сайте PyDev.org, а также в блоге Fabio Zadrozny.

Введение в git.

Система спроектирована как набор программ, специально разработанных с учётом их использования в скриптах. Это позволяет удобно создавать специализированные системы контроля версий на базе Git или пользовательские интерфейсы. Например, Cogito является именно таким примером фронтенда к репозиториям Git. А StGit использует Git для управления коллекцией патчей.

Git поддерживает быстрое разделение и слияние версий, включает инструменты для визуализации и навигации по нелинейной истории разработки. Как и Darcs, BitKeeper, Mercurial, SVK, Bazaar и Monotone, Git предоставляет каждому разработчику локальную копию всей истории разработки, изменения копируются из одного репозитория в другой.

Удалённый доступ к репозиториям Git обеспечивается git-daemon, SSH, или HTTP сервером. TCP-сервис git-daemon входит в дистрибутив Git и является наряду с SSH наиболее распространённым и надёжным методом доступа. HTTP метод доступа, несмотря на ряд ограничений, очень популярен в контролируемых сетях, потому что позволяет использование существующих конфигураций сетевых фильтров.

Установка.

cd /usr/ports/devel/git
make && make install

Для публичного доступа к репозиторию можно воспользоваться git-daemon.
Также возможен доступ через http (апач+dav+gitweb).
Я же выбрал более простой и надёжный путь - ssh.

Для начала определимся с сервером.
Создаем пользователя, который будет работать с репозиториями, а так же являться администратором gitosis: gituser (создаем без пароля).

$sudo adduser gituser

При создании, в качестве домашней указываем корневую директорию с репозиториями.

Для начала мы сосредоточимся на авторизации пользователя через ssh.
Для этого, проверим настройки sshd, примерно как здесь.

Устанавливаем gitosis, набор скриптов, которые выполняются при открытии ssh-сессии, позволяют использовать ssh ключи для авторизации в репозиториях, а также освобождают от необходимости создавать много пользователей в системе для доступа к репозиториям.

$git clone git://eagain.net/gitosis.git
$cd gitosis
$sudo python setup.py install

Далее надо создать gitosis-хостинг с авторизацией только по ключам:
То есть проинициализировать репозиторий самого gitosis в указанной нами директории.
Я решил управление gitosis оставить на сервере.

$ssh-keygen -t rsa

Эта команда создает в домашней директории пользователя gituser пару id_rsa и id_rsa.pub. Первый файл - секретный, должен быть закрыт от любого пользователя на системе, а так же не передаваться по сети.
Второй ключ публичный, мы его должны передать в gitosis при инициализации gitosis. Его рекомендуют скопировать в директорию, доступную всем для чтения, например /tmp . Далее инициализируем gitosis и его репозиторий.
(Первые две команды, в случае, если у вас не установлен sudo.)

#cd /usr/ports/security/sudo ; make install clean
#rehash
#sudo -H -u gituser gitosis-init < />Initialized empty Git repository in /tank/gitrepos/repositories/gitosis-admin.git/
Reinitialized existing Git repository in /tank/gitrepos/repositories/gitosis-admin.git/

ключ -H обязателен, иначе команда sudo будет выполняться в домашнюю директорию предыдущего пользователя (например /root).

Теперь у нас есть несколько директорий в домашней директории gituser. Папка repositories предназначена для хранения репозиториев, там уже находится репозиторий настроек gitosis (gitosis-admin).

Если у вас старый setuptools, рекомендуют прописать следующие права:

sudo chmod 755 ~/repositories/gitosis-admin.git/hooks/post-update

Далее, заходим под пользователем gituser и забираем репозиторий администрирования gitosis:

$git clone gituser@YOUR_SERVER_HOSTNAME:gitosis-admin.git
$cd gitosis-admin

Это удаленно, а у так как у нас админ на этом же хосте, то локально:

#su gituser
$cd ~/tmp
$git clone ~/repositories/gitosis-admin.git gitosis-admin
$cd gitosis-admin

Создание "репозиториев" в gitosis.
Редактируем файл gitosis.conf:

[group projectteam]
members = vasya
writable = project

где project - название будущего репозитория.

Создаем публичный ключ в клиенте windows.
Для этого используем пакет msysGit. Я выбрал portable версию, ибо нам из пакета нужен только генератор ssh ключей (PortableGit\bin\ssh-keygen.exe).

>ssh-keygen -C “vasya” -t rsa

Обычно пара сохраняется в папку c:\\Documents and Settings\\Username\\.ssh на XP или c:\\Users\\Username\\.ssh на Vista. Заливаем публичный ключ (vasya.pub) в директорию gitosis-admin/keydir, место куда мы извлекли репозиторий настроек gitosis.

"Пушим" настройки в репозиторий gitosis.

git add keydir/vasya.pub
git commit -a -m "Allow vasya write access to project"
git push

После этого проверить, что файл конфигурации изменился (есть ссылка в домашней директории gituser), а также скопировались ключи в ~/repositories/gitosis-admin.git/gitosis-export/keydir. При загрузке в репозиторий gitosis сам извлекает изменившееся файлы в директорию gitosis-admin.

Создаем репозиторий на сервере под юзером gituser:

$mkdir ~/repositories/project.git
$cd project.git
$git --bare init

--bare обозначает, что у нас нет намерения хранить файлы самого проекта на сервере, только diff и файлы, которые генерирует сам git (проще говоря, структура git репозитория). Что кстати, совершенно достаточно даже для Git Plugin for Trac, который мы намереваемся установить.

Теперь нам необходимо создать ветку (branch), иначе EGit будет ругаться на отсутствие оных. Выполнить push на полностью пустом репозитории нельзя.
Для первого коммита автоматически создается бранч с именем master, в него же по умолчанию попадают следующие коммиты

#su gituser
$cd ~/tmp
$git clone ~/repositories/project.git project
$cd project
$echo "test" > test
$git add test
$git commit -a -m "initial branch"
$git push origin master

Попробуем получить проект через ssh с помощью плагина EGit.
Установка eclipse и самого плагина очень проста.
В меню eclipse выбираем File-Import, Git Repository. Выбираем протокол git+ssh:// , указываем путь:

git+ssh://gituser@SERVER/project.git

Самое главное! eclipse прописывает путь к ssh, как $HOME/ssh. Его необходимо поправить на $HOME/.ssh в меню:
Window-Preferences - General - Network Connection - SSH2. Там же можно управлять ключами и просматривать их. Если eclipse не найдет ключи ничего забираться не будет.
Дальнейшие действия по добавлению проекта интуитивно понятны.

Единственное, в новой версии появилась галочка Import projects after clone, которую надо снять, ибо она у меня привела к пустому списку проектов, попробуйте, может у вас получится. Это не страшно, по вышеприведенному примеру указано как просто сделать share project с извлеченного проекта на диске (плюс показано ниже).

Можно также забрать проект через консоль:

Запускаем PortableGit\git-cmd.bat и выполняем:

>git clone gituser@SERVER:project.git

Далее, создаем проект в eclipse, добавляем в него наш извлеченный проект (Import-File System), жмем на проекте Team-Share (Git) и все, наш проект теперь помечен, как гит репозиторий. Пробуем менять файлы, коммитить и пушить.



Если возникают какие-либо проблемы, то смотрим /var/log/auth.log .
А также в eclipse ( Help - About Eclipse - Configuration Details - View Error Log).
Также можно добавить после строчки [gitosis] в gitosis.conf:

loglevel=DEBUG

При задании которого при обращении к gitosis (через консольный клиент) будут выведена дополнительная информация при ошибках.

Об установке багтрекера Trac для git, а также использовании git в Visual Studio в следующий раз.

Введение в git.

Система спроектирована как набор программ, специально разработанных с учётом их использования в скриптах. Это позволяет удобно создавать специализированные системы контроля версий на базе Git или пользовательские интерфейсы. Например, Cogito является именно таким примером фронтенда к репозиториям Git. А StGit использует Git для управления коллекцией патчей.

Git поддерживает быстрое разделение и слияние версий, включает инструменты для визуализации и навигации по нелинейной истории разработки. Как и Darcs, BitKeeper, Mercurial, SVK, Bazaar и Monotone, Git предоставляет каждому разработчику локальную копию всей истории разработки, изменения копируются из одного репозитория в другой.

Удалённый доступ к репозиториям Git обеспечивается git-daemon, SSH, или HTTP сервером. TCP-сервис git-daemon входит в дистрибутив Git и является наряду с SSH наиболее распространённым и надёжным методом доступа. HTTP метод доступа, несмотря на ряд ограничений, очень популярен в контролируемых сетях, потому что позволяет использование существующих конфигураций сетевых фильтров.

Установка.

cd /usr/ports/devel/git
make && make install

Для публичного доступа к репозиторию можно воспользоваться git-daemon.
Также возможен доступ через http (апач+dav+gitweb).
Я же выбрал более простой и надёжный путь - ssh.

Для начала определимся с сервером.
Создаем пользователя, который будет работать с репозиториями, а так же являться администратором gitosis: gituser (создаем без пароля).

$sudo adduser gituser

При создании, в качестве домашней указываем корневую директорию с репозиториями.

Для начала мы сосредоточимся на авторизации пользователя через ssh.
Для этого, проверим настройки sshd, примерно как здесь.

Устанавливаем gitosis, набор скриптов, которые выполняются при открытии ssh-сессии, позволяют использовать ssh ключи для авторизации в репозиториях, а также освобождают от необходимости создавать много пользователей в системе для доступа к репозиториям.

$git clone git://eagain.net/gitosis.git
$cd gitosis
$sudo python setup.py install

Далее надо создать gitosis-хостинг с авторизацией только по ключам:
То есть проинициализировать репозиторий самого gitosis в указанной нами директории.
Я решил управление gitosis оставить на сервере.

$ssh-keygen -t rsa

Эта команда создает в домашней директории пользователя gituser пару id_rsa и id_rsa.pub. Первый файл - секретный, должен быть закрыт от любого пользователя на системе, а так же не передаваться по сети.
Второй ключ публичный, мы его должны передать в gitosis при инициализации gitosis. Его рекомендуют скопировать в директорию, доступную всем для чтения, например /tmp . Далее инициализируем gitosis и его репозиторий.
(Первые две команды, в случае, если у вас не установлен sudo.)

#cd /usr/ports/security/sudo ; make install clean
#rehash
#sudo -H -u gituser gitosis-init < />Initialized empty Git repository in /tank/gitrepos/repositories/gitosis-admin.git/
Reinitialized existing Git repository in /tank/gitrepos/repositories/gitosis-admin.git/

ключ -H обязателен, иначе команда sudo будет выполняться в домашнюю директорию предыдущего пользователя (например /root).

Теперь у нас есть несколько директорий в домашней директории gituser. Папка repositories предназначена для хранения репозиториев, там уже находится репозиторий настроек gitosis (gitosis-admin).

Если у вас старый setuptools, рекомендуют прописать следующие права:

sudo chmod 755 ~/repositories/gitosis-admin.git/hooks/post-update

Далее, заходим под пользователем gituser и забираем репозиторий администрирования gitosis:

$git clone gituser@YOUR_SERVER_HOSTNAME:gitosis-admin.git
$cd gitosis-admin

Это удаленно, а у так как у нас админ на этом же хосте, то локально:

#su gituser
$cd ~/tmp
$git clone ~/repositories/gitosis-admin.git gitosis-admin
$cd gitosis-admin

Создание "репозиториев" в gitosis.
Редактируем файл gitosis.conf:

[group projectteam]
members = vasya
writable = project

где project - название будущего репозитория.

Создаем публичный ключ в клиенте windows.
Для этого используем пакет msysGit. Я выбрал portable версию, ибо нам из пакета нужен только генератор ssh ключей (PortableGit\bin\ssh-keygen.exe).

>ssh-keygen -C “vasya” -t rsa

Обычно пара сохраняется в папку c:\\Documents and Settings\\Username\\.ssh на XP или c:\\Users\\Username\\.ssh на Vista. Заливаем публичный ключ (vasya.pub) в директорию gitosis-admin/keydir, место куда мы извлекли репозиторий настроек gitosis.

"Пушим" настройки в репозиторий gitosis.

git add keydir/vasya.pub
git commit -a -m "Allow vasya write access to project"
git push

После этого проверить, что файл конфигурации изменился (есть ссылка в домашней директории gituser), а также скопировались ключи в ~/repositories/gitosis-admin.git/gitosis-export/keydir. При загрузке в репозиторий gitosis сам извлекает изменившееся файлы в директорию gitosis-admin.

Создаем репозиторий на сервере под юзером gituser:

$mkdir ~/repositories/project.git
$cd project.git
$git --bare init

--bare обозначает, что у нас нет намерения хранить файлы самого проекта на сервере, только diff и файлы, которые генерирует сам git (проще говоря, структура git репозитория). Что кстати, совершенно достаточно даже для Git Plugin for Trac, который мы намереваемся установить.

Теперь нам необходимо создать ветку (branch), иначе EGit будет ругаться на отсутствие оных. Выполнить push на полностью пустом репозитории нельзя.
Для первого коммита автоматически создается бранч с именем master, в него же по умолчанию попадают следующие коммиты

#su gituser
$cd ~/tmp
$git clone ~/repositories/project.git project
$cd project
$echo "test" > test
$git add test
$git commit -a -m "initial branch"
$git push origin master

Попробуем получить проект через ssh с помощью плагина EGit.
Установка eclipse и самого плагина очень проста.
В меню eclipse выбираем File-Import, Git Repository. Выбираем протокол git+ssh:// , указываем путь:

git+ssh://gituser@SERVER/project.git

Самое главное! eclipse прописывает путь к ssh, как $HOME/ssh. Его необходимо поправить на $HOME/.ssh в меню:
Window-Preferences - General - Network Connection - SSH2. Там же можно управлять ключами и просматривать их. Если eclipse не найдет ключи ничего забираться не будет.
Дальнейшие действия по добавлению проекта интуитивно понятны.

Единственное, в новой версии появилась галочка Import projects after clone, которую надо снять, ибо она у меня привела к пустому списку проектов, попробуйте, может у вас получится. Это не страшно, по вышеприведенному примеру указано как просто сделать share project с извлеченного проекта на диске (плюс показано ниже).

Можно также забрать проект через консоль:

Запускаем PortableGit\git-cmd.bat и выполняем:

>git clone gituser@SERVER:project.git

Далее, создаем проект в eclipse, добавляем в него наш извлеченный проект (Import-File System), жмем на проекте Team-Share (Git) и все, наш проект теперь помечен, как гит репозиторий. Пробуем менять файлы, коммитить и пушить.



Если возникают какие-либо проблемы, то смотрим /var/log/auth.log .
А также в eclipse ( Help - About Eclipse - Configuration Details - View Error Log).
Также можно добавить после строчки [gitosis] в gitosis.conf:

loglevel=DEBUG

При задании которого при обращении к gitosis (через консольный клиент) будут выведена дополнительная информация при ошибках.

Об установке багтрекера Trac для git, а также использовании git в Visual Studio в следующий раз.