Единственный минус такого подхода заключается в том, что, без дополнительных усилий, не получится воспользоваться в своём коде командой вида import module_a. Для этого потребуется кое-что сделать. <…>
Проблема хорошо решается вызовом pip install -e . в окружении, в котором вы работаете (pyenv/conda/etc). В этом случае можно просто импортировать тестируемый пакет в тесты.
Не совсем понял, зачем внутри src находятся тесты. Они сами по себе не то чтобы являются исходным кодом пакета. Плюс, если использовать пример setup.py из https://github.com/pypa/sampleproject, где есть строчка packages=find_packages(where="src"), то при упаковке пакета папка test попадёт внутрь. Нужна ли она пользователю пакета? Мне так не кажется. Хотя при более тонкой настройке packages, естественно, она в пакет не попадёт.
Согласен. Но всё таки это вполне себе функция. Или нечто под неё мимикрирующее. Я привел цитату из официальной документации Python. Использование классов менее распространено, согласно той же документации.
Мой поинт в том, что ваше высказывание слишком категорично, в то время согласно официальной документации оно вполне покрывает большую часть случаев.
Почему? В словаре питона написано буквально "A function returning another function, usually applied as a function transformation using the @wrapper syntax".
А в моем случае с производительностью всё не так прекрасно. Я использую VS Code для C++ разработки, и с WSL1 работало всё значительно шустрее. Буквально в десятки раз. И я такой не один. Issue можно посмотреть вот тут: https://github.com/microsoft/WSL/issues/4197#issuecomment-604592340
Appget имеет уже большинство фич из roadmap майков, и они отлично работают. Какую-то часть потребностей он вполне удовлетворяет, например установка программ одной командой или обновление всего установленного одной командой. Не знаю, насколько он был сложен или лёгок в реализации, но на данный момент он куда более полноценен и закончен.
Ну, "упакованный" объект — это что значит? Я вот не очень понимаю. Box как бы проводит аналогию с реальным миром (с коробкой), но назначение его или особенности устройства всё ещё не понятны при прочтении. Как слово-placeholder, которое можно заменить на что-то другое со схожим значением без потери смысла. Например Storage, Container, Holder или даже Any, Object.
Да, я подозреваю, что это что-то по типу намеренного unhandled exception в Python: если повезёт, что программа не крашится. И что так делать не надо. Но весь код на Rust, который я читал, пестрит использованием unwrap.
Видимо это связано с теми же явлениями, что и в каком-нибудь Haskell. Ведь хаскелисты отлично умеют читать свои программы, но для остальных это больше тайные манускрипты, чем код. В данном случае чуть меньше всё это проявляется, но всё-таки.
Что угодно становится проще, если на это писать, конечно же. Просто таких ощущений у меня не возникает, когда читаешь код на javascript, С#, Ada, PHP, Java и даже Tcl. А тут возникают.
Да, полностью согласен, это отталкивает. Меньше не всегда значит лучше.
А ещё больше отталкивает наличие большого количество "слов" в коде программы, несущих чисто "служебное" значение и не имеющих прямое отношение к логике программы. Например, "unwrap" и его вариации, встречающиеся постоянно, "cloned", "get_mut", "boxed".
Ещё в Rust много контейнеров, которые названы "дефолтными" словами, никак не описывающими их назначение. Обычно мне такие слова linter подчёркивает в других языках, как плохие. Например, Box. Из-за этого сильно страдает выразительность языка, как мне кажется.
Всё это меня смущает настолько, что по большей части именно из-за этого я до сих пор откладываю полноценное изучение Rust.
Ну, нельзя же запихать все зависимость внутрь IDE. Что-то да останется снаружи. Плюс, если они "идут", это значит что внутри IDE сделан такой же, только неявный, package manager, который всё это скачивает и встраивает в структуру.
Что именно входит в дистрибутив? В дистрибутив чего?
Помимо libc и самого языка Си в проекте могут использоваться библиотеки. Например, RTOS, FS и пр. Каким образом они подключаются и компилируются в C? Да как придётся. Хорошо, если есть CMake или Make в репозитории. Иначе бери, копируй файлы, компилируй всё сам. Так что непонятно что вас смутило в системе, которая значительно упрощает управление зависимостями проекта.
Вместо std::memcpy можно использовать более типобезопасный std::copy. По скорости он не уступает, а бывает даже быстрее. Да и сырой указатель не очень красиво, C-way.
Когда Atollic стал бесплатным, я очень обрадовался, потому что это цельная специализированная IDE с множеством полезных инструментов для отладки. Плюс, она отлично работала с дополнением Eclipse для поддержки CMake проектов. Единственное, она использовала старую версию CDT и не поддерживала всех современных фич языка C++. Но была надежда на то, что в будущем это пофиксят.
А потом вышла Stm32CubeIDE и сломала совместимость с CMake плагинами. Хочется работать — генерируюй проект в CubeMX. А когда у тебя CI и всё проекты на CMake + в основном ты пользуешься libopencm3… Пришлось оставить надежду и уйти на VS Code. Очень жаль, что так вышло.
Тут так и напрашивается ссылочка на аппаратный менеджер паролей. Например, Pastilda https://bitbucket.org/thirdpin_team/pastilda
Правда есть всё таки есть несколько проблем, такие как:
паяльник;
оставил пастильду включенной и разблокированной, можно быстренько прибежать и слямзить пароль.
Но по крайней мере мастер пароль будет в безопасности всегда.
Проблема хорошо решается вызовом
pip install -e .в окружении, в котором вы работаете (pyenv/conda/etc). В этом случае можно просто импортировать тестируемый пакет в тесты.Не совсем понял, зачем внутри src находятся тесты. Они сами по себе не то чтобы являются исходным кодом пакета. Плюс, если использовать пример setup.py из https://github.com/pypa/sampleproject, где есть строчка
packages=find_packages(where="src"), то при упаковке пакета папка test попадёт внутрь. Нужна ли она пользователю пакета? Мне так не кажется. Хотя при более тонкой настройкеpackages, естественно, она в пакет не попадёт.В остальном приличный гайд. Советы полезные.
С этим полностью согласен.
Согласен. Но всё таки это вполне себе функция. Или нечто под неё мимикрирующее. Я привел цитату из официальной документации Python. Использование классов менее распространено, согласно той же документации.
Мой поинт в том, что ваше высказывание слишком категорично, в то время согласно официальной документации оно вполне покрывает большую часть случаев.
Почему? В словаре питона написано буквально "A function returning another function, usually applied as a function transformation using the @wrapper syntax".
Есть ещё Nuitka, компилятор питон кода. Собирал ей достаточно сложные проекты — работало. Для простых я думаю отлично будет функционировать.
Есть такая прекрасная библиотека magic_enum. Работает отлично, не требует никаких дополнительных обвесов вокруг enum-ов.
https://github.com/Neargye/magic_enum
А в моем случае с производительностью всё не так прекрасно. Я использую VS Code для C++ разработки, и с WSL1 работало всё значительно шустрее. Буквально в десятки раз. И я такой не один. Issue можно посмотреть вот тут: https://github.com/microsoft/WSL/issues/4197#issuecomment-604592340
Appget имеет уже большинство фич из roadmap майков, и они отлично работают. Какую-то часть потребностей он вполне удовлетворяет, например установка программ одной командой или обновление всего установленного одной командой. Не знаю, насколько он был сложен или лёгок в реализации, но на данный момент он куда более полноценен и закончен.
Хм. Спасибо, такой специфики не знал, изучу.
Но всё-таки
Boxмне всё ещё кажется не подходящим названием, хоть и общеиспользуемым.Они уже в процессе, похоже. Как минимум в roadmap есть, что уже не может не радовать.
Ну, "упакованный" объект — это что значит? Я вот не очень понимаю.
Boxкак бы проводит аналогию с реальным миром (с коробкой), но назначение его или особенности устройства всё ещё не понятны при прочтении. Как слово-placeholder, которое можно заменить на что-то другое со схожим значением без потери смысла. Например Storage, Container, Holder или даже Any, Object.Да, я подозреваю, что это что-то по типу намеренного
unhandled exceptionв Python: если повезёт, что программа не крашится. И что так делать не надо. Но весь код на Rust, который я читал, пестрит использованиемunwrap.Видимо это связано с теми же явлениями, что и в каком-нибудь Haskell. Ведь хаскелисты отлично умеют читать свои программы, но для остальных это больше тайные манускрипты, чем код. В данном случае чуть меньше всё это проявляется, но всё-таки.
Что угодно становится проще, если на это писать, конечно же. Просто таких ощущений у меня не возникает, когда читаешь код на javascript, С#, Ada, PHP, Java и даже Tcl. А тут возникают.
Да, полностью согласен, это отталкивает. Меньше не всегда значит лучше.
А ещё больше отталкивает наличие большого количество "слов" в коде программы, несущих чисто "служебное" значение и не имеющих прямое отношение к логике программы. Например, "unwrap" и его вариации, встречающиеся постоянно, "cloned", "get_mut", "boxed".
Ещё в Rust много контейнеров, которые названы "дефолтными" словами, никак не описывающими их назначение. Обычно мне такие слова linter подчёркивает в других языках, как плохие. Например, Box. Из-за этого сильно страдает выразительность языка, как мне кажется.
Всё это меня смущает настолько, что по большей части именно из-за этого я до сих пор откладываю полноценное изучение Rust.
Ну, нельзя же запихать все зависимость внутрь IDE. Что-то да останется снаружи. Плюс, если они "идут", это значит что внутри IDE сделан такой же, только неявный, package manager, который всё это скачивает и встраивает в структуру.
Что именно входит в дистрибутив? В дистрибутив чего?
Помимо libc и самого языка Си в проекте могут использоваться библиотеки. Например, RTOS, FS и пр. Каким образом они подключаются и компилируются в C? Да как придётся. Хорошо, если есть CMake или Make в репозитории. Иначе бери, копируй файлы, компилируй всё сам. Так что непонятно что вас смутило в системе, которая значительно упрощает управление зависимостями проекта.
Вместо std::memcpy можно использовать более типобезопасный std::copy. По скорости он не уступает, а бывает даже быстрее. Да и сырой указатель не очень красиво, C-way.
Когда Atollic стал бесплатным, я очень обрадовался, потому что это цельная специализированная IDE с множеством полезных инструментов для отладки. Плюс, она отлично работала с дополнением Eclipse для поддержки CMake проектов. Единственное, она использовала старую версию CDT и не поддерживала всех современных фич языка C++. Но была надежда на то, что в будущем это пофиксят.
А потом вышла Stm32CubeIDE и сломала совместимость с CMake плагинами. Хочется работать — генерируюй проект в CubeMX. А когда у тебя CI и всё проекты на CMake + в основном ты пользуешься libopencm3… Пришлось оставить надежду и уйти на VS Code. Очень жаль, что так вышло.
Тут так и напрашивается ссылочка на аппаратный менеджер паролей. Например, Pastilda https://bitbucket.org/thirdpin_team/pastilda
Правда есть всё таки есть несколько проблем, такие как:
Но по крайней мере мастер пароль будет в безопасности всегда.