TGTGInsighttelegram intelligenceLIVE / telegram public index
← Python Заметки

TGINSIGHT SIMILAR POSTS

Најди сличен содржај

Изворен канал @pythonotes · Post #210 · 3 фев.

Что делать если нужно поставить какую-то Python-библиотеку а root-прав нет? То есть в систему библиотеку никак и ничего не поставить. Есть как минимум два способа это решить правильно! 🔸 Сделать виртуальное окружение и ставить там что угодно. Это позволит создать полностью независимое исполняемое окружение для ваших приложений. Все библиотеки будут храниться в домашней директории юзера а значит доступ на запись имеется. Создать очень просто: python3 -m venv ~/venvs/myenvname Теперь активируем окружение # Linux source ~/venvs/myenvname/bin/activate # Windows %userprofile%\venvs\myenvname\Scripts\activate.bat Можно ставить любые библиотеки и запускать приложение. Это стандартный метод работы с любым проектом. Если еще не используете его, то пора начинать. Даже при наличии root доступа! 🔸 Бывает, что нет возможности запустить приложение из своего виртуального окружения. Например, его запускает какой-то сервис от вашего юзера и вставить активацию окружения вы не можете. В этом случае можно установить библиотеки для Python не глобально в систему, а только для юзера. Выполните этот код в консоли: python3 -m site Вы получите что-то такое: sys.path = [ '/home/user', '/usr/lib/python37.zip', '/usr/lib/python3.7', '/usr/lib/python3.7/lib-dynload', '/home/user/.local/lib/python3.7/site-packages', ... ] USER_BASE: '/home/user/.local' USER_SITE: '/home/user/.local/lib/python3.7/site-packages' ENABLE_USER_SITE: True Нас интересует параметр USER_SITE. Это путь к пользовательским библиотекам, которые доступны по умолчанию, если они есть. Именно сюда будут устанавливаться модули если добавить флаг --user при установке чего-либо через pip pip install --user requests Для этой команды не нужны root-права. После неё можно запускать системный интерпретатор без виртуальных окружений и установленная библиотека будет доступна для текущего юзера. Параметр USER_BASE показывает корневую директорию для хранения user-библиотек. Её можно изменить с помощью переменной окружения PYTHONUSERBASE export PYTHONUSERBASE=~/pylibs python3 -m site ... USER_BASE: '/home/user/pylibs' USER_SITE: '/home/user/pylibs/lib/python3.7/site-packages' Получается некоторое подобие виртуального окружения для бедных 😁 которое можно менять через эту переменную (не делайте так!Лучше venv!) 🔸 Дописывание пути в PYTHONPATH Этот способ не входит в список "двух правильных", но тоже рабочий. Здесь придётся сделать всё несколько сложней. Сначала ставим библиотеку в любое место указывая путь установки pip3 install -t ~/mylibs modulename Библиотека установится без привязки к какому-либо интерпретатору. То есть по умолчанию не будет видна. Теперь в нужный момент добавляем этот путь в sys.path или в PYTHONPATH. Не буду советовать так делать. Единственный раз когда этот способ мне пригодился и решил поставленную задачу, это при создании общей библиотеки для кластера компьютеров. Модули лежат в сети и подгружаются для всех из одного и того же места. То есть обновлять файлы требуется только один раз а не на всех хосты отдельно. Минусы такого подхода: ▫️Нужно всем хостам пробить нужный путь в .bashrc или ещё куда-то чтобы он сетапился на старте. ▫️Чем больше хостов тем больше нагрузка на сеть. Иногда такой способ не подходит именно по этой причине. Тогда Ansible вам в помощь. ▫️Не очень подходит если хосты с разными операционками. Некоторые библиотеки различаются для Linux и Windows (там, где есть бинарники) и приходится мудрить более сложные схемы. #tricks#basic

Резултати

Пронајдени 1 слични објави

Пребарај: #statementofclaim

当前筛选 #statementofclaim清除筛选
English Law Report

@enlawreport · Post #1882 · 24.01.2026 г., 04:52

✍️Как реально “собирается” Statement of Claim по английскому праву (без магии и пафоса) Большинство думает, что Statement of Claim пишется так: “сел, вдохновился, красиво изложил и подал”. На практике это больше похоже на инженерную сборку, где любое слабое звено ломает весь корпус: факт, доказательство, причинность, формулировка, логика. Вот как это устроено, если делать грамотно. 1) Client intake & instructions (вход клиента и “что вообще хотим”) Первый шаг не про право. Он про реальность. ✅ Что именно произошло? ✅ Чего клиент хочет на выходе? Деньги? запрет? декларацию? ✅ Где спор будет жить: High Court, арбитраж, другая юрисдикция? 📌 Ошибка №1: начать писать “претензию” до того, как ты понял цель и площадку. 2) Fact collection & evidence assembly (факты + доказательства) Ты не пишешь историю. Ты строишь доказуемую картину. 🔹 контракты, переписка, инвойсы, акты 🔹 хронология событий (по дням и документам) 🔹 ключевые моменты: кто что сделал/не сделал/сказал/подписал ⚠️ Если тут слабое место, то дальше всё будет “вилами по воде”. Не будет доказательств = не будет кейса. 3) Legal qualification (юридическая квалификация) Только теперь включается право. ✅ какое право применимо ✅ какие causes of action (основания иска) ✅ какие duty/standards (обязанность и стандарт нарушения) 📌 Ошибка №2: “мне кажется это fraud / negligence” без привязки к фактам и элементам. 4) Issue framing (упаковка спора в понятные суду вопросы) Тут ты превращаешь хаос в структуру: где breach (нарушение) какая liability theory (теория ответственности) как работает causation logic (причинная связь) ⚠️ Главный убийца кейса: causation gap Когда вред вроде есть, нарушение вроде есть… а связать их логически нельзя. Иногда честный вывод тут один: discard (не тратить время, закрыть направление, поменять стратегию). 5) Structure of Statement of Claim (скелет документа) Хороший Statement of Claim читается как точный маршрут: Parties & Jurisdiction Factual background Breach & wrongdoing Causation Damages Relief sought 📌 Ошибка №3: “слишком много эмоций” и “слишком мало конструкции”. Суд не нанимался угадывать. 6) Drafting & iteration (черновики, правки, “снять жир”) Один драфт почти никогда не бывает финальным. версии документа внутренний ревью переписывание слабых мест вычищение лишних слов, повторов и противоречий Это этап, где текст становится оружием, а не “рассказом”. 7) Verification & consistency check (проверка на прочность) Финальная проверка выглядит просто, но это самая дорогая часть работы: ✅ каждое утверждение = подкреплено доказательством ✅ внутренняя логика без дыр ✅ противоречия убраны ✅ narrative совпадает с документами И только после этого документ превращается в: 📄Filed pleading (поданное процессуальное заявление) 🎯 Главная мысль Statement of Claim это не “текст юриста”. Это система: факты → доказательства → право → причинность → структура → проверка. Если ты пропустил один блок, то в суде тебя “разберут” за 10 минут. #EnglishLawReport#Litigation#StatementOfClaim#LegalWriting#DisputeStrategy#Arbitration#CommercialCourt