구성 파일을 제한합니다.d 파일, 파일 이름이 설정 파일 이름과 일치하도록 합니까?

묘사

편집:user profile ~/플러그인을 설치하는 방법에 대한 설명이 곳곳에 있습니다.라이언/프로필.clj
그러나 2.0.0에서는 구성 파일이 사용됩니다.d 의미: 사용자 프로필은 프로필에 있을 수 있습니다.clj, 또는 프로필 아래의 모든 파일.d. 그러나 설정 파일은 오류를 일으키지 않고 한 위치에만 존재할 수 있습니다.
이것은 사람을 곤혹스럽게 할 수도 있는 것 같다.
또한 Windows 설치 프로그램에서 자바 cmd in:user를 설정할 수 있기를 바랍니다.사용을 고려하고 있습니다.https://github.com/cgrand/sjacket개요 파일을 분석하고 변수를 삽입하거나 변경합니다. 주석, 레이아웃, 메타데이터를 흐트러뜨리지 않습니다.
근데 개인 정보 때문에나는 사용자가 어디에 있는지 모른다.
제안:
1) 사용자 수준 구성 파일을 다음 위치 중 하나로 제한합니다.
a) ~/.라이언/프로필.clj
혹은
b) ~/.라이언/프로필.d/.clj
이것은 모든 설정 파일을 제한한다.단일 구성 파일을 포함하는 d 파일입니다.
2) 블랙리스트 기본 프로필(사용자, 개발자...)개인 정보에 나타나지 않도록 하세요.d

토론 #1

그러나 최종 목표는 무엇입니까?왜 당신은 :user 파일의 정확한 출처를 알아야 합니까?

토론 #2

여기에 두 가지 다른 문제가 있을 수 있습니다.
1
일반적인 경우 (프로필의 출처를 찾으려는 나의 소망을 무시함), 내장 프로필이 프로필에 나타날 수 있도록 허용합니다.d는 틀리기 쉬우며 쓸모가 없다.
소개의 목적.d는 디렉터리에 프로필을 넣어서 설치를 간소화하는 것 같습니다.이것은 위대한 사용자 정의 프로필입니다.
그러나 개요 파일이 여러 소스에 존재하면 통합 정책이 잘못됩니다.따라서 프로필에 내장된 프로필 (예: user) 을 넣는 것은 나쁜 생각입니다.d. 표준 관례를 따르는 모든 사람이 프로필을 편집해서 플러그인을 설치할 수 있기 때문이다.clj에서 오류가 발생할 수 있습니다. 드래그망을 통해 프로필을 훑어보는 방법을 알아야 합니다.d 중복된 정의를 찾아서 성명을 다른 파일로 이동합니다.이것은 사람을 인상 깊게 하는 물건이다.d는 막으려고 했지만 내장된 프로필에 대해서는 더 나빠질 수 있습니다.
따라서, 이 때문에, 나는 우리가 프로필에 내장된 프로필을 금지해야 한다고 생각한다.d
2
Windows leiningen 설치 프로그램이 업데이트할 수 있도록:javacmd 정의를 수정하고 사용자가 선택한 JDK를 가리키도록 하기 위해서:user를 포함하는 사용자 프로필을 찾을 수 있기를 바랍니다.이것은 결코 불가능한 것이 아니지만, 프로필에 있는 모든 파일을 분석할 필요가 없다면 더욱 쉽다.d 내장 프로필을 정의할 때 정의를 찾습니다.d부터 시작하는 것은 좋은 생각이 아닌 것 같다.
병합 정책의 오류를 감안하여 모든 프로필을 자신의 파일에 두는 것은 좋은 생각인 것 같다. 왜냐하면 프로필 간에 병합 오류가 발생하지 않도록 보장하기 때문이다.d 파일을 관리하기 쉽습니다.

토론 #셋

내장 프로필을 덮어쓰는 것을 금지하는 것을 별로 좋아하지 않습니다.우리는 어떤 설정 파일이 출하되어야 하는지에 대해 결정을 내리고 있지만, 나는 모든 사람에게 정확하다고 100% 믿지 않기 때문에 사람들이 그것을 덮어쓸 권리가 있어야 한다.그러나 충돌을 걱정할 경우, 내장 프로필 이름을 이름 공간에 한정된 키로 전환할 수 있습니다.
사용자급 설정 파일에 특례:dev가 있는데 이것은 항상 오류입니다.이런 상황이 검출되었을 때 나는 경고를 보내지 않을 것이다.개발자 프로필은 project.clj에만 포함됩니다.
나는 상술한 파일로 명명된 파일에서만 파일을 찾는 것에 동의한다~/.lein/profiles.d/.이것은 일리가 있는 것이다.아마도 @dakrone는 그의 최초의 생각이었기 때문에 끼어들 수 있을 것이다.

토론 #4

profiles.d에 있는 파일이 하나의 프로필만 포함될 수 있다면, 이것은 profiles.clj와 같은 형식이 아니라, 후자는 프로필 이름을 프로필에 비추어야 할 수도 있습니다.

토론 #5

프로필에는 두 가지 주요 용례가 있다.d:
1) 사용자가 자신의 프로필을 서로 다른 파일로 분리할 수 있도록 한다. 만약 그들이 이렇게 하면 더욱 깔끔하고 아름답다고 생각한다면.
2) 사용자나 사용자를 대표하는 에이전트가 사용자 정의 프로필을 프로필에 배치할 수 있도록 한다.d
최초의 증강 문제는 사례2)를 논의했다.
나는 누구를 생각하는 것이 무엇을 생각하는 것보다 더 유용하다고 생각한다.
만약 우리가 사례 1)만 처리한다면 문제가 없을 것이다.사용자는 프로필 간에 충돌하는 프로필이 없는지 확인할 수 있습니다.clj와 개인 정보.d.
그러나 사례 2)에 대해 사용자나 에이전트는 그들이 프로필에 넣고 있는 프로필이 정확하다는 것을 확신해야 한다.d 구성 파일의 구성 파일과 충돌하지 않습니다.clj, 그렇지 않으면 일이 틀어질 거야.
거의 확실한 것은 사용자가 설정 파일에 존재한다는 것이다.clj, 나는 우리가 반드시 금지해야 한다고 생각한다:user가 개인 자료에 들어가는 것을.d.
: dev가 설정 파일에서 금지되었습니다.clj (profiles.d?라고 가정합니다.
나는 다른 내장된 물건에 그다지 관심이 없다.

토론 #6

tldr#871은 맞춤형 프로필을 줄이는 데 있어 장점이 있고 실제 원가가 없다.
그러나 내장 프로그램에 있어서 유일한 장점은 디렉터리 구조가 더욱 깔끔하다는 것이다. 그러나 비용은 일을 더욱 쉽게 틀리고 혼란스럽게 할 수 있다

토론 #7

.나는 네가 '내장' 을 사용하는 방식이 나와 다르다는 것을 알았다.나는 Leiningen이 자체로 가지고 있는 프로필을 가리킨다. 그래서 :base, :test, :repl. 그러나 기본적으로 활성화된 프로필을 가리킨다.
IIRCprofiles.d의 최초 동기는 실제적으로 민감한 설정을 다른 설정 파일에서 분리하여 비민감한 위치를 버전 제어로 검사할 수 있도록 하는 것입니다.프로그램 프로필을 만들기 위해 설계된 것이 아닙니다.

토론 #8

예, 구성 파일이 있는 경우d 디렉터리는 설정 파일의 이름으로 제한됩니다. 예를 들어, 우리의 작업 설정에는 단독 설정 파일 이름이 있을 수 없습니다.

토론 #9

@dakrone 왜 안 해요?너는 그것들을 두 개의 다른 파일에 배치할 수 없니?
@ 기술은 확실하지 않습니다. :user 프로필만 사용합니다.내가 주로 걱정하는 것은 모든 플러그인 문서가 :user에서 편집profiles.clj을 통해 플러그인을 설치하는 방법을 설명하고 있다는 것이다. 나는 설명에서 "편집profiles.clj하고 싶지 않다. profiles.d의 한 파일이 정의:user된 경우를 제외하고는 그곳에서 편집해야 한다. 그렇지 않으면 오류가 발생할 것이다."라고 말하고 싶지 않다.고통만 많이 가져올 뿐, 이런 유연성은 누구에게도 도움이 되지 않기 때문이다.

토론 #10

@djpowell은 모든 기존 문서에 대한 관점이 좋습니다.이 점을 감안하여 :user 프로필을 profiles.clj로 제한할 수 있습니다.
나는 @dakrone이 언급한 문제를 이해하지 못한다. 만약 그가 특별히 여러 개의 파일이나 다른 것에 서명하는 것을 피하려고 하지 않는다면.

토론 #11

받아들일 수 있어userprofiles.clj에만 넣을 수 있어.보기에 매우 합리적이다.
그러나 IDE나 유사 제품이 여러 개의 프로필을 첨부하고 하나의 프로필로 제한하기를 원한다면 peopleprofiles.d 디렉터리를 파괴하기 전에 이 프로필이 폐기되었다는 경고를 보내야 한다.우리는 그것을 3.0.0로 바꿀 수 있다.

토론 #12

@hyPiRion:profiles.d는 2.0.0

토론 #13

이후에 추가된 거야. 네 말이 맞아. 내 댓글을 무시해.

토론 #14

IRC:

<technomancy> djpowell: ok, so my thoughts are basically that I like the
              idea of no map wrapper and that I'm not 100% sure about the
              limitation on the user profile, but the great thing about
              restrictions is that you can lift them in the future without
              breaking compatibility
<technomancy> so I'm ok with introducing profiles.d with this restriction
              given that we can revisit it to possibly make it less picky
              in the future; I don't think we necessarily have to make a
              Final Choice for 2.1.0.