Дизайн модуля Powershell - Export-ModuleMember

function powershell powershell-module

6444 просмотра

1 ответ

Я создаю модуль, который экспортирует командлет, который я хотел бы сделать доступным через мой профиль. Реализация этого командлета распределена по нескольким файлам реализации, которые содержат функции реализации, которые я не хочу делать общедоступными. Поэтому я использую Export-ModuleMember, чтобы скрыть их.

get_something.psm1

import-module .\get_something_impl.psm1

function Get-Something {
    [cmdletbinding()]
    Get-SomethingImplementation
}

Export-ModuleMember -Function Get-Something

Затем я добавляю get_something.psm1 в свой профиль. При экспорте только Get-Something все мои функции реализации остаются «частными».

Проблема, с которой я сталкиваюсь, заключается в том, что при использовании команды Export-ModuleMember мне приходится импортировать модуль в мои файлы реализации каждый раз, когда мне нужна функция внутри него. Например, предположим, что у меня есть модуль person.psm1 с функцией Get-Person, который мне нужно вызывать во всех моих файлах реализации. Теперь я должен импортировать person.psm1 в каждый файл, который мне нужен для вызова Get-Person. Это результат использования Export-ModuleMember -Function Get-Something. Без него мне нужно было бы импортировать person.psm1 только один раз, и он был бы доступен.

По сути, Export-ModuleMember не только блокирует мою реализацию извне, но и мою собственную реализацию.

Ожидается ли это и считается ли нормальным аспектом проектирования модулей Powershell?

Автор: Matthew S Источник Размещён: 13.11.2019 11:33

Ответы (1)

18 плюса

Решение

Это было на самом деле немного споров во время разработки модулей. Первоначально Export-ModuleMember требовался для экспорта любой функции. Это стало утомительным и ограничивающим. Таким образом, по умолчанию все функции из модуля являются видимыми, а переменные и псевдонимы - нет, если вы никогда не использовали Export-ModuleMember в .PSM1.

Если вы используете Export-ModuleMember, он начинает ограничивать этот список. Возможно, неплохо было бы экспортировать меньшее количество функций, но вы должны использовать это несколько осторожно.

Вы можете написать:

Export-ModuleMember -Function a,b,c

который экспортирует несколько функций.

или же

Export-ModuleMember -Function *

Последнее эквивалентно отсутствию Export-ModuleMember в целом.

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

Другая вещь, которую вы, похоже, спрашиваете, - как лучше всего обрабатывать зависимости модуля. В настоящее время довольно часто при написании скрипта импортировать один или два модуля, так же как довольно часто включать сборку или две в проект C #. Если вы делаете это внутри модуля, вы можете использовать флаг -Global на Import-Module и избегать использования -Force (который перезагрузит модуль). Это повышает эффективность повторного использования модуля в различных функциях. Это также уменьшает вероятность возникновения «циклических» (разгрузочных и перезагружаемых) операций с модулем, что, к сожалению, во многих модулях не очень хорошо.

Альтернативой ссылкам на модуль в каждой функции является использование манифеста модуля (Get-Help New-ModuleManifest). Манифесты модулей очень интересны и требуют изучения для многих частей разработки модулей. Если вы включите модуль в список RequiredModules манифеста модуля, он будет автоматически загружен до импорта модуля (по крайней мере, в PowerShell 3 и более поздних версиях). Если вы включите модуль в список NestedModules манифеста модуля, он будет загружен как часть модуля, а команды, экспортированные модулем, будут экспортированы вашим модулем.

Дизайн модуля - хитрый зверь, но это очень полезно делать правильно. Удачи.

Автор: Start-Automating Размещён: 06.03.2014 06:44
Вопросы из категории :
32x32