'.concat(d,"
"))),k(d))){"none"==d.style.display&&(d.style.display="block");var c=document.createElement("div");c.className="ginlined-content",c.appendChild(d),s=c}if(r){var u=document.getElementById(r);if(!u)return!1;var g=u.cloneNode(!0);g.style.height=t.height,g.style.maxWidth=t.width,h(g,"ginlined-content"),s=g}if(!s)return console.error("Unable to append inline slide content",t),!1;o.style.height=t.height,o.style.width=t.width,o.appendChild(s),this.events["inlineclose"+r]=a("click",{onElement:o.querySelectorAll(".gtrigger-close"),withCallback:function(e){e.preventDefault(),l.close()}}),T(n)&&n()}function Z(e,t,i,n){var s=e.querySelector(".gslide-media"),l=function(e){var t=e.url,i=e.allow,n=e.callback,s=e.appendTo,l=document.createElement("iframe");return l.className="vimeo-video gvideo",l.src=t,l.style.width="100%",l.style.height="100%",i&&l.setAttribute("allow",i),l.onload=function(){h(l,"node-ready"),T(n)&&n()},s&&s.appendChild(l),l}({url:t.href,callback:n});s.parentNode.style.maxWidth=t.width,s.parentNode.style.height=t.height,s.appendChild(l)}var $=function(){function e(){var i=arguments.length>0&&void 0!==arguments[0]?arguments[0]:{};t(this,e),this.defaults={href:"",sizes:"",srcset:"",title:"",type:"",description:"",alt:"",descPosition:"bottom",effect:"",width:"",height:"",content:!1,zoomable:!0,draggable:!0},L(i)&&(this.defaults=l(this.defaults,i))}return n(e,[{key:"sourceType",value:function(e){var t=e;if(null!==(e=e.toLowerCase()).match(/\.(jpeg|jpg|jpe|gif|png|apn|webp|avif|svg)/))return"image";if(e.match(/(youtube\.com|youtube-nocookie\.com)\/watch\?v=([a-zA-Z0-9\-_]+)/)||e.match(/youtu\.be\/([a-zA-Z0-9\-_]+)/)||e.match(/(youtube\.com|youtube-nocookie\.com)\/embed\/([a-zA-Z0-9\-_]+)/))return"video";if(e.match(/vimeo\.com\/([0-9]*)/))return"video";if(null!==e.match(/\.(mp4|ogg|webm|mov)/))return"video";if(null!==e.match(/\.(mp3|wav|wma|aac|ogg)/))return"audio";if(e.indexOf("#")>-1&&""!==t.split("#").pop().trim())return"inline";return e.indexOf("goajax=true")>-1?"ajax":"external"}},{key:"parseConfig",value:function(e,t){var i=this,n=l({descPosition:t.descPosition},this.defaults);if(L(e)&&!k(e)){O(e,"type")||(O(e,"content")&&e.content?e.type="inline":O(e,"href")&&(e.type=this.sourceType(e.href)));var s=l(n,e);return this.setSize(s,t),s}var r="",a=e.getAttribute("data-glightbox"),h=e.nodeName.toLowerCase();if("a"===h&&(r=e.href),"img"===h&&(r=e.src,n.alt=e.alt),n.href=r,o(n,(function(s,l){O(t,l)&&"width"!==l&&(n[l]=t[l]);var o=e.dataset[l];I(o)||(n[l]=i.sanitizeValue(o))})),n.content&&(n.type="inline"),!n.type&&r&&(n.type=this.sourceType(r)),I(a)){if(!n.title&&"a"==h){var d=e.title;I(d)||""===d||(n.title=d)}if(!n.title&&"img"==h){var c=e.alt;I(c)||""===c||(n.title=c)}}else{var u=[];o(n,(function(e,t){u.push(";\\s?"+t)})),u=u.join("\\s?:|"),""!==a.trim()&&o(n,(function(e,t){var s=a,l=new RegExp("s?"+t+"s?:s?(.*?)("+u+"s?:|$)"),o=s.match(l);if(o&&o.length&&o[1]){var r=o[1].trim().replace(/;\s*$/,"");n[t]=i.sanitizeValue(r)}}))}if(n.description&&"."===n.description.substring(0,1)){var g;try{g=document.querySelector(n.description).innerHTML}catch(e){if(!(e instanceof DOMException))throw e}g&&(n.description=g)}if(!n.description){var v=e.querySelector(".glightbox-desc");v&&(n.description=v.innerHTML)}return this.setSize(n,t,e),this.slideConfig=n,n}},{key:"setSize",value:function(e,t){var i=arguments.length>2&&void 0!==arguments[2]?arguments[2]:null,n="video"==e.type?this.checkSize(t.videosWidth):this.checkSize(t.width),s=this.checkSize(t.height);return e.width=O(e,"width")&&""!==e.width?this.checkSize(e.width):n,e.height=O(e,"height")&&""!==e.height?this.checkSize(e.height):s,i&&"image"==e.type&&(e._hasCustomWidth=!!i.dataset.width,e._hasCustomHeight=!!i.dataset.height),e}},{key:"checkSize",value:function(e){return M(e)?"".concat(e,"px"):e}},{key:"sanitizeValue",value:function(e){return"true"!==e&&"false"!==e?e:"true"===e}}]),e}(),U=function(){function e(i,n,s){t(this,e),this.element=i,this.instance=n,this.index=s}return n(e,[{key:"setContent",value:function(){var e=this,t=arguments.length>0&&void 0!==arguments[0]?arguments[0]:null,i=arguments.length>1&&void 0!==arguments[1]&&arguments[1];if(c(t,"loaded"))return!1;var n=this.instance.settings,s=this.slideConfig,l=w();T(n.beforeSlideLoad)&&n.beforeSlideLoad({index:this.index,slide:t,player:!1});var o=s.type,r=s.descPosition,a=t.querySelector(".gslide-media"),d=t.querySelector(".gslide-title"),u=t.querySelector(".gslide-desc"),g=t.querySelector(".gdesc-inner"),v=i,f="gSlideTitle_"+this.index,p="gSlideDesc_"+this.index;if(T(n.afterSlideLoad)&&(v=function(){T(i)&&i(),n.afterSlideLoad({index:e.index,slide:t,player:e.instance.getSlidePlayerInstance(e.index)})}),""==s.title&&""==s.description?g&&g.parentNode.parentNode.removeChild(g.parentNode):(d&&""!==s.title?(d.id=f,d.innerHTML=s.title):d.parentNode.removeChild(d),u&&""!==s.description?(u.id=p,l&&n.moreLength>0?(s.smallDescription=this.slideShortDesc(s.description,n.moreLength,n.moreText),u.innerHTML=s.smallDescription,this.descriptionEvents(u,s)):u.innerHTML=s.description):u.parentNode.removeChild(u),h(a.parentNode,"desc-".concat(r)),h(g.parentNode,"description-".concat(r))),h(a,"gslide-".concat(o)),h(t,"loaded"),"video"!==o){if("external"!==o)return"inline"===o?(G.apply(this.instance,[t,s,this.index,v]),void(s.draggable&&new V({dragEl:t.querySelector(".gslide-inline"),toleranceX:n.dragToleranceX,toleranceY:n.dragToleranceY,slide:t,instance:this.instance}))):void("image"!==o?T(v)&&v():j(t,s,this.index,(function(){var i=t.querySelector("img");s.draggable&&new V({dragEl:i,toleranceX:n.dragToleranceX,toleranceY:n.dragToleranceY,slide:t,instance:e.instance}),s.zoomable&&i.naturalWidth>i.offsetWidth&&(h(i,"zoomable"),new H(i,t,(function(){e.instance.resize()}))),T(v)&&v()})));Z.apply(this,[t,s,this.index,v])}else F.apply(this.instance,[t,s,this.index,v])}},{key:"slideShortDesc",value:function(e){var t=arguments.length>1&&void 0!==arguments[1]?arguments[1]:50,i=arguments.length>2&&void 0!==arguments[2]&&arguments[2],n=document.createElement("div");n.innerHTML=e;var s=n.innerText,l=i;if((e=s.trim()).length<=t)return e;var o=e.substr(0,t-1);return l?(n=null,o+'... '+i+""):o}},{key:"descriptionEvents",value:function(e,t){var i=this,n=e.querySelector(".desc-more");if(!n)return!1;a("click",{onElement:n,withCallback:function(e,n){e.preventDefault();var s=document.body,l=u(n,".gslide-desc");if(!l)return!1;l.innerHTML=t.description,h(s,"gdesc-open");var o=a("click",{onElement:[s,u(l,".gslide-description")],withCallback:function(e,n){"a"!==e.target.nodeName.toLowerCase()&&(d(s,"gdesc-open"),h(s,"gdesc-closed"),l.innerHTML=t.smallDescription,i.descriptionEvents(l,t),setTimeout((function(){d(s,"gdesc-closed")}),400),o.destroy())}})}})}},{key:"create",value:function(){return m(this.instance.settings.slideHTML)}},{key:"getConfig",value:function(){k(this.element)||this.element.hasOwnProperty("draggable")||(this.element.draggable=this.instance.settings.draggable);var e=new $(this.instance.settings.slideExtraAttributes);return this.slideConfig=e.parseConfig(this.element,this.instance.settings),this.slideConfig}}]),e}(),J=w(),K=null!==w()||void 0!==document.createTouch||"ontouchstart"in window||"onmsgesturechange"in window||navigator.msMaxTouchPoints,Q=document.getElementsByTagName("html")[0],ee={selector:".glightbox",elements:null,skin:"clean",theme:"clean",closeButton:!0,startAt:null,autoplayVideos:!0,autofocusVideos:!0,descPosition:"bottom",width:"900px",height:"506px",videosWidth:"960px",beforeSlideChange:null,afterSlideChange:null,beforeSlideLoad:null,afterSlideLoad:null,slideInserted:null,slideRemoved:null,slideExtraAttributes:null,onOpen:null,onClose:null,loop:!1,zoomable:!0,draggable:!0,dragAutoSnap:!1,dragToleranceX:40,dragToleranceY:65,preload:!0,oneSlidePerOpen:!1,touchNavigation:!0,touchFollowAxis:!0,keyboardNavigation:!0,closeOnOutsideClick:!0,plugins:!1,plyr:{css:"https://cdn.plyr.io/3.6.8/plyr.css",js:"https://cdn.plyr.io/3.6.8/plyr.js",config:{ratio:"16:9",fullscreen:{enabled:!0,iosNative:!0},youtube:{noCookie:!0,rel:0,showinfo:0,iv_load_policy:3},vimeo:{byline:!1,portrait:!1,title:!1,transparent:!1}}},openEffect:"zoom",closeEffect:"zoom",slideEffect:"slide",moreText:"See more",moreLength:60,cssEfects:{fade:{in:"fadeIn",out:"fadeOut"},zoom:{in:"zoomIn",out:"zoomOut"},slide:{in:"slideInRight",out:"slideOutLeft"},slideBack:{in:"slideInLeft",out:"slideOutRight"},none:{in:"none",out:"none"}},svg:{close:'',next:'',prev:''},slideHTML:'',lightboxHTML:'\n \n \n
'},te=function(){function e(){var i=arguments.length>0&&void 0!==arguments[0]?arguments[0]:{};t(this,e),this.customOptions=i,this.settings=l(ee,i),this.effectsClasses=this.getAnimationClasses(),this.videoPlayers={},this.apiEvents=[],this.fullElementsList=!1}return n(e,[{key:"init",value:function(){var e=this,t=this.getSelector();t&&(this.baseEvents=a("click",{onElement:t,withCallback:function(t,i){t.preventDefault(),e.open(i)}})),this.elements=this.getElements()}},{key:"open",value:function(){var e=arguments.length>0&&void 0!==arguments[0]?arguments[0]:null,t=arguments.length>1&&void 0!==arguments[1]?arguments[1]:null;if(0==this.elements.length)return!1;this.activeSlide=null,this.prevActiveSlideIndex=null,this.prevActiveSlide=null;var i=M(t)?t:this.settings.startAt;if(k(e)){var n=e.getAttribute("data-gallery");n&&(this.fullElementsList=this.elements,this.elements=this.getGalleryElements(this.elements,n)),I(i)&&(i=this.getElementIndex(e))<0&&(i=0)}M(i)||(i=0),this.build(),g(this.overlay,"none"==this.settings.openEffect?"none":this.settings.cssEfects.fade.in);var s=document.body,l=window.innerWidth-document.documentElement.clientWidth;if(l>0){var o=document.createElement("style");o.type="text/css",o.className="gcss-styles",o.innerText=".gscrollbar-fixer {margin-right: ".concat(l,"px}"),document.head.appendChild(o),h(s,"gscrollbar-fixer")}h(s,"glightbox-open"),h(Q,"glightbox-open"),J&&(h(document.body,"glightbox-mobile"),this.settings.slideEffect="slide"),this.showSlide(i,!0),1==this.elements.length?(h(this.prevButton,"glightbox-button-hidden"),h(this.nextButton,"glightbox-button-hidden")):(d(this.prevButton,"glightbox-button-hidden"),d(this.nextButton,"glightbox-button-hidden")),this.lightboxOpen=!0,this.trigger("open"),T(this.settings.onOpen)&&this.settings.onOpen(),K&&this.settings.touchNavigation&&B(this),this.settings.keyboardNavigation&&X(this)}},{key:"openAt",value:function(){var e=arguments.length>0&&void 0!==arguments[0]?arguments[0]:0;this.open(null,e)}},{key:"showSlide",value:function(){var e=this,t=arguments.length>0&&void 0!==arguments[0]?arguments[0]:0,i=arguments.length>1&&void 0!==arguments[1]&&arguments[1];f(this.loader),this.index=parseInt(t);var n=this.slidesContainer.querySelector(".current");n&&d(n,"current"),this.slideAnimateOut();var s=this.slidesContainer.querySelectorAll(".gslide")[t];if(c(s,"loaded"))this.slideAnimateIn(s,i),p(this.loader);else{f(this.loader);var l=this.elements[t],o={index:this.index,slide:s,slideNode:s,slideConfig:l.slideConfig,slideIndex:this.index,trigger:l.node,player:null};this.trigger("slide_before_load",o),l.instance.setContent(s,(function(){p(e.loader),e.resize(),e.slideAnimateIn(s,i),e.trigger("slide_after_load",o)}))}this.slideDescription=s.querySelector(".gslide-description"),this.slideDescriptionContained=this.slideDescription&&c(this.slideDescription.parentNode,"gslide-media"),this.settings.preload&&(this.preloadSlide(t+1),this.preloadSlide(t-1)),this.updateNavigationClasses(),this.activeSlide=s}},{key:"preloadSlide",value:function(e){var t=this;if(e<0||e>this.elements.length-1)return!1;if(I(this.elements[e]))return!1;var i=this.slidesContainer.querySelectorAll(".gslide")[e];if(c(i,"loaded"))return!1;var n=this.elements[e],s=n.type,l={index:e,slide:i,slideNode:i,slideConfig:n.slideConfig,slideIndex:e,trigger:n.node,player:null};this.trigger("slide_before_load",l),"video"==s||"external"==s?setTimeout((function(){n.instance.setContent(i,(function(){t.trigger("slide_after_load",l)}))}),200):n.instance.setContent(i,(function(){t.trigger("slide_after_load",l)}))}},{key:"prevSlide",value:function(){this.goToSlide(this.index-1)}},{key:"nextSlide",value:function(){this.goToSlide(this.index+1)}},{key:"goToSlide",value:function(){var e=arguments.length>0&&void 0!==arguments[0]&&arguments[0];if(this.prevActiveSlide=this.activeSlide,this.prevActiveSlideIndex=this.index,!this.loop()&&(e<0||e>this.elements.length-1))return!1;e<0?e=this.elements.length-1:e>=this.elements.length&&(e=0),this.showSlide(e)}},{key:"insertSlide",value:function(){var e=arguments.length>0&&void 0!==arguments[0]?arguments[0]:{},t=arguments.length>1&&void 0!==arguments[1]?arguments[1]:-1;t<0&&(t=this.elements.length);var i=new U(e,this,t),n=i.getConfig(),s=l({},n),o=i.create(),r=this.elements.length-1;s.index=t,s.node=!1,s.instance=i,s.slideConfig=n,this.elements.splice(t,0,s);var a=null,h=null;if(this.slidesContainer){if(t>r)this.slidesContainer.appendChild(o);else{var d=this.slidesContainer.querySelectorAll(".gslide")[t];this.slidesContainer.insertBefore(o,d)}(this.settings.preload&&0==this.index&&0==t||this.index-1==t||this.index+1==t)&&this.preloadSlide(t),0==this.index&&0==t&&(this.index=1),this.updateNavigationClasses(),a=this.slidesContainer.querySelectorAll(".gslide")[t],h=this.getSlidePlayerInstance(t),s.slideNode=a}this.trigger("slide_inserted",{index:t,slide:a,slideNode:a,slideConfig:n,slideIndex:t,trigger:null,player:h}),T(this.settings.slideInserted)&&this.settings.slideInserted({index:t,slide:a,player:h})}},{key:"removeSlide",value:function(){var e=arguments.length>0&&void 0!==arguments[0]?arguments[0]:-1;if(e<0||e>this.elements.length-1)return!1;var t=this.slidesContainer&&this.slidesContainer.querySelectorAll(".gslide")[e];t&&(this.getActiveSlideIndex()==e&&(e==this.elements.length-1?this.prevSlide():this.nextSlide()),t.parentNode.removeChild(t)),this.elements.splice(e,1),this.trigger("slide_removed",e),T(this.settings.slideRemoved)&&this.settings.slideRemoved(e)}},{key:"slideAnimateIn",value:function(e,t){var i=this,n=e.querySelector(".gslide-media"),s=e.querySelector(".gslide-description"),l={index:this.prevActiveSlideIndex,slide:this.prevActiveSlide,slideNode:this.prevActiveSlide,slideIndex:this.prevActiveSlide,slideConfig:I(this.prevActiveSlideIndex)?null:this.elements[this.prevActiveSlideIndex].slideConfig,trigger:I(this.prevActiveSlideIndex)?null:this.elements[this.prevActiveSlideIndex].node,player:this.getSlidePlayerInstance(this.prevActiveSlideIndex)},o={index:this.index,slide:this.activeSlide,slideNode:this.activeSlide,slideConfig:this.elements[this.index].slideConfig,slideIndex:this.index,trigger:this.elements[this.index].node,player:this.getSlidePlayerInstance(this.index)};if(n.offsetWidth>0&&s&&(p(s),s.style.display=""),d(e,this.effectsClasses),t)g(e,this.settings.cssEfects[this.settings.openEffect].in,(function(){i.settings.autoplayVideos&&i.slidePlayerPlay(e),i.trigger("slide_changed",{prev:l,current:o}),T(i.settings.afterSlideChange)&&i.settings.afterSlideChange.apply(i,[l,o])}));else{var r=this.settings.slideEffect,a="none"!==r?this.settings.cssEfects[r].in:r;this.prevActiveSlideIndex>this.index&&"slide"==this.settings.slideEffect&&(a=this.settings.cssEfects.slideBack.in),g(e,a,(function(){i.settings.autoplayVideos&&i.slidePlayerPlay(e),i.trigger("slide_changed",{prev:l,current:o}),T(i.settings.afterSlideChange)&&i.settings.afterSlideChange.apply(i,[l,o])}))}setTimeout((function(){i.resize(e)}),100),h(e,"current")}},{key:"slideAnimateOut",value:function(){if(!this.prevActiveSlide)return!1;var e=this.prevActiveSlide;d(e,this.effectsClasses),h(e,"prev");var t=this.settings.slideEffect,i="none"!==t?this.settings.cssEfects[t].out:t;this.slidePlayerPause(e),this.trigger("slide_before_change",{prev:{index:this.prevActiveSlideIndex,slide:this.prevActiveSlide,slideNode:this.prevActiveSlide,slideIndex:this.prevActiveSlideIndex,slideConfig:I(this.prevActiveSlideIndex)?null:this.elements[this.prevActiveSlideIndex].slideConfig,trigger:I(this.prevActiveSlideIndex)?null:this.elements[this.prevActiveSlideIndex].node,player:this.getSlidePlayerInstance(this.prevActiveSlideIndex)},current:{index:this.index,slide:this.activeSlide,slideNode:this.activeSlide,slideIndex:this.index,slideConfig:this.elements[this.index].slideConfig,trigger:this.elements[this.index].node,player:this.getSlidePlayerInstance(this.index)}}),T(this.settings.beforeSlideChange)&&this.settings.beforeSlideChange.apply(this,[{index:this.prevActiveSlideIndex,slide:this.prevActiveSlide,player:this.getSlidePlayerInstance(this.prevActiveSlideIndex)},{index:this.index,slide:this.activeSlide,player:this.getSlidePlayerInstance(this.index)}]),this.prevActiveSlideIndex>this.index&&"slide"==this.settings.slideEffect&&(i=this.settings.cssEfects.slideBack.out),g(e,i,(function(){var t=e.querySelector(".ginner-container"),i=e.querySelector(".gslide-media"),n=e.querySelector(".gslide-description");t.style.transform="",i.style.transform="",d(i,"greset"),i.style.opacity="",n&&(n.style.opacity=""),d(e,"prev")}))}},{key:"getAllPlayers",value:function(){return this.videoPlayers}},{key:"getSlidePlayerInstance",value:function(e){var t="gvideo"+e,i=this.getAllPlayers();return!(!O(i,t)||!i[t])&&i[t]}},{key:"stopSlideVideo",value:function(e){if(k(e)){var t=e.querySelector(".gvideo-wrapper");t&&(e=t.getAttribute("data-index"))}console.log("stopSlideVideo is deprecated, use slidePlayerPause");var i=this.getSlidePlayerInstance(e);i&&i.playing&&i.pause()}},{key:"slidePlayerPause",value:function(e){if(k(e)){var t=e.querySelector(".gvideo-wrapper");t&&(e=t.getAttribute("data-index"))}var i=this.getSlidePlayerInstance(e);i&&i.playing&&i.pause()}},{key:"playSlideVideo",value:function(e){if(k(e)){var t=e.querySelector(".gvideo-wrapper");t&&(e=t.getAttribute("data-index"))}console.log("playSlideVideo is deprecated, use slidePlayerPlay");var i=this.getSlidePlayerInstance(e);i&&!i.playing&&i.play()}},{key:"slidePlayerPlay",value:function(e){if(k(e)){var t=e.querySelector(".gvideo-wrapper");t&&(e=t.getAttribute("data-index"))}var i=this.getSlidePlayerInstance(e);i&&!i.playing&&(i.play(),this.settings.autofocusVideos&&i.elements.container.focus())}},{key:"setElements",value:function(e){var t=this;this.settings.elements=!1;var i=[];e&&e.length&&o(e,(function(e,n){var s=new U(e,t,n),o=s.getConfig(),r=l({},o);r.slideConfig=o,r.instance=s,r.index=n,i.push(r)})),this.elements=i,this.lightboxOpen&&(this.slidesContainer.innerHTML="",this.elements.length&&(o(this.elements,(function(){var e=m(t.settings.slideHTML);t.slidesContainer.appendChild(e)})),this.showSlide(0,!0)))}},{key:"getElementIndex",value:function(e){var t=!1;return o(this.elements,(function(i,n){if(O(i,"node")&&i.node==e)return t=n,!0})),t}},{key:"getElements",value:function(){var e=this,t=[];this.elements=this.elements?this.elements:[],!I(this.settings.elements)&&E(this.settings.elements)&&this.settings.elements.length&&o(this.settings.elements,(function(i,n){var s=new U(i,e,n),o=s.getConfig(),r=l({},o);r.node=!1,r.index=n,r.instance=s,r.slideConfig=o,t.push(r)}));var i=!1;return this.getSelector()&&(i=document.querySelectorAll(this.getSelector())),i?(o(i,(function(i,n){var s=new U(i,e,n),o=s.getConfig(),r=l({},o);r.node=i,r.index=n,r.instance=s,r.slideConfig=o,r.gallery=i.getAttribute("data-gallery"),t.push(r)})),t):t}},{key:"getGalleryElements",value:function(e,t){return e.filter((function(e){return e.gallery==t}))}},{key:"getSelector",value:function(){return!this.settings.elements&&(this.settings.selector&&"data-"==this.settings.selector.substring(0,5)?"*[".concat(this.settings.selector,"]"):this.settings.selector)}},{key:"getActiveSlide",value:function(){return this.slidesContainer.querySelectorAll(".gslide")[this.index]}},{key:"getActiveSlideIndex",value:function(){return this.index}},{key:"getAnimationClasses",value:function(){var e=[];for(var t in this.settings.cssEfects)if(this.settings.cssEfects.hasOwnProperty(t)){var i=this.settings.cssEfects[t];e.push("g".concat(i.in)),e.push("g".concat(i.out))}return e.join(" ")}},{key:"build",value:function(){var e=this;if(this.built)return!1;var t=document.body.childNodes,i=[];o(t,(function(e){e.parentNode==document.body&&"#"!==e.nodeName.charAt(0)&&e.hasAttribute&&!e.hasAttribute("aria-hidden")&&(i.push(e),e.setAttribute("aria-hidden","true"))}));var n=O(this.settings.svg,"next")?this.settings.svg.next:"",s=O(this.settings.svg,"prev")?this.settings.svg.prev:"",l=O(this.settings.svg,"close")?this.settings.svg.close:"",r=this.settings.lightboxHTML;r=m(r=(r=(r=r.replace(/{nextSVG}/g,n)).replace(/{prevSVG}/g,s)).replace(/{closeSVG}/g,l)),document.body.appendChild(r);var d=document.getElementById("glightbox-body");this.modal=d;var g=d.querySelector(".gclose");this.prevButton=d.querySelector(".gprev"),this.nextButton=d.querySelector(".gnext"),this.overlay=d.querySelector(".goverlay"),this.loader=d.querySelector(".gloader"),this.slidesContainer=document.getElementById("glightbox-slider"),this.bodyHiddenChildElms=i,this.events={},h(this.modal,"glightbox-"+this.settings.skin),this.settings.closeButton&&g&&(this.events.close=a("click",{onElement:g,withCallback:function(t,i){t.preventDefault(),e.close()}})),g&&!this.settings.closeButton&&g.parentNode.removeChild(g),this.nextButton&&(this.events.next=a("click",{onElement:this.nextButton,withCallback:function(t,i){t.preventDefault(),e.nextSlide()}})),this.prevButton&&(this.events.prev=a("click",{onElement:this.prevButton,withCallback:function(t,i){t.preventDefault(),e.prevSlide()}})),this.settings.closeOnOutsideClick&&(this.events.outClose=a("click",{onElement:d,withCallback:function(t,i){e.preventOutsideClick||c(document.body,"glightbox-mobile")||u(t.target,".ginner-container")||u(t.target,".gbtn")||c(t.target,"gnext")||c(t.target,"gprev")||e.close()}})),o(this.elements,(function(t,i){e.slidesContainer.appendChild(t.instance.create()),t.slideNode=e.slidesContainer.querySelectorAll(".gslide")[i]})),K&&h(document.body,"glightbox-touch"),this.events.resize=a("resize",{onElement:window,withCallback:function(){e.resize()}}),this.built=!0}},{key:"resize",value:function(){var e=arguments.length>0&&void 0!==arguments[0]?arguments[0]:null;if((e=e||this.activeSlide)&&!c(e,"zoomed")){var t=y(),i=e.querySelector(".gvideo-wrapper"),n=e.querySelector(".gslide-image"),s=this.slideDescription,l=t.width,o=t.height;if(l<=768?h(document.body,"glightbox-mobile"):d(document.body,"glightbox-mobile"),i||n){var r=!1;if(s&&(c(s,"description-bottom")||c(s,"description-top"))&&!c(s,"gabsolute")&&(r=!0),n)if(l<=768)n.querySelector("img");else if(r){var a=s.offsetHeight,u=n.querySelector("img");u.setAttribute("style","max-height: calc(100vh - ".concat(a,"px)")),s.setAttribute("style","max-width: ".concat(u.offsetWidth,"px;"))}if(i){var g=O(this.settings.plyr.config,"ratio")?this.settings.plyr.config.ratio:"";if(!g){var v=i.clientWidth,f=i.clientHeight,p=v/f;g="".concat(v/p,":").concat(f/p)}var m=g.split(":"),x=this.settings.videosWidth,b=this.settings.videosWidth,S=(b=M(x)||-1!==x.indexOf("px")?parseInt(x):-1!==x.indexOf("vw")?l*parseInt(x)/100:-1!==x.indexOf("vh")?o*parseInt(x)/100:-1!==x.indexOf("%")?l*parseInt(x)/100:parseInt(i.clientWidth))/(parseInt(m[0])/parseInt(m[1]));if(S=Math.floor(S),r&&(o-=s.offsetHeight),b>l||S>o||o\n \n \n \n \n
\nHatch v1.6.0¶
Hatch v1.6.0 brings improvements to build environments, better handling of dynamic metadata, and support for tools like Visual Studio Code.
Build environments¶
Originally, the environment interface method for providing builder sub-environments was intended to be used in conjunction with some cleanup logic in order to provide a fresh setup every time. However, this is unnecessary in practice because build dependencies rarely change.
Without caching, repeat build environment use is slow which affects the following scenarios:
- the
buildcommand - commands that read project metadata, like
dep hash, if any fields are set dynamically
Now a new environment interface method build_environment_exists is used by Hatch to determine whether or not it has already been created, for implementations that have a caching mechanism.
The virtual environment type now uses this method to cache build environments.
Project metadata¶
Dynamically defined metadata is now supported everywhere, thanks to the new caching of virtual build environments.
A project metadata command is introduced that displays the fully resolved metadata. The output format is JSON unless a field is specified as an argument.
For example, if you checkout a project that is built by Hatch, like FastAPI, and run:
hatch project metadata readme
+only the readme text will be displayed. If the content is in Markdown, then Rich will render it directly in your terminal:
Virtual environment location¶
The virtual environment type now uses a flat layout for storage in the configured virtual environment directory if the directory resides somewhere within the project root or if it is set to a .virtualenvs directory within the user's home directory.
For example, if you define the following Hatch configuration:
[dirs.env]
+virtual = ".hatch"
+and the following matrix:
[[tool.hatch.envs.test.matrix]]
+python = ["3.7", "3.8", "3.9", "3.10", "3.11"]
+[[envs.test.matrix]]
+python = ["3.7", "3.8", "3.9", "3.10", "3.11"]
+then locating environments with the following command:
hatch env find test
+will show that the general directory structure is:
.hatch
+├── test.py3.7
+├── test.py3.8
+├── test.py3.9
+├── test.py3.10
+└── test.py3.11
+This flat structure is required for detection of virtual environments by tools like Visual Studio Code and PyCharm.
Additionally, the virtual environment type now supports a path option to specify an explicit path that all inherited environments will share, such as the common .venv.
Migration script improvements¶
The script used to migrate existing projects from setuptools has been improved to handle more edge cases that were encountered in the wild and now no longer modifies the formatting of existing pyproject.toml configuration.
Hatchling¶
Hatch now depends on Hatchling v1.11.0, which was also just released.
Environment version source¶
A new env version source is available that allows for the project version to be defined by an environment variable.
Relaxed version bumping¶
The standard version scheme now supports a validate-bump option that when set to false will forego the check when updating the version that the desired version is higher than the current version.
This use case comes from Project Jupyter:
A common pattern we use in Jupyter is to bump to a
.dev0minor version bump after making a release. If we have a bug fix that needs to go out in the interim, we'd rather not be forced to create a branch every time.
Hatch v1.8.0¶
Hatch v1.8.0 brings Python distribution management, static analysis and formatting backed by Ruff, and binaries for every platform.
Installation made easy¶
One thing that has been a perpetual problem for Hatch and other Python applications is that Python itself is a dependency. You, and more importantly your users, need to in some way get Python before your software can even be used. The recommended way to go about that is platform-dependent and even differs based on your target audience. I viewed this as a central UX problem for Hatch and so severe that I took a bit of a hiatus to solve it.
Luckily, I have to my satisfaction solved this problem in the form of PyApp. It is a runtime installer for Python projects written in Rust. Apps are distributed as standalone executables as users have come to expect and bootstrapping occurs upon the first invocation. Here is an example of what you would see the first time you run a binary from this release:
Now that we have binaries, creating installers for different platforms becomes trivial. Starting with this release not only are binaries available for every platform but also we have installers for Windows and macOS. The installer for macOS is signed using a certificate from the same account used to sign the official distributions from https://www.python.org, so users will not get any security pop-ups. Shout out to @ewdurbin for their extreme generosity in setting up multiple certificates in their free time!
These installers and binaries are now the recommended way to install and update Hatch. These binaries have built-in management so you can update to the latest version by running hatch self update.
Windows signing
In future we will sign the installers for Windows but I did not have time to look into how that works. macOS signing took way longer than I anticipated 
Python management¶
For a long time I and other users have desired that Hatch gain the ability to manage Python distributions. In my mind this was always blocked on a better installation experience because there was sort of a chicken-or-egg problem where you want a Python manager but you first need Python. No longer is that the case!
The new python command group allows for easy installation of various distributions to arbitrary locations which are then added to your PATH by default. Hatch supports CPython and PyPy distributions:
Virtual environment Python resolution¶
The virtual environment type is now far more intelligent when resolving the parent distribution to use and guarantees that, when no specific version is requested, the resolved distribution will always be compatible with the project.
Additionally, when a requested version cannot be found on PATH it will automatically be downloaded and managed internally.
Static analysis¶
There is a new fmt command, backed entirely by Ruff, that checks and fixes your code for formatting and linting issues.
Starting with this release, Hatch maintains default settings that are guaranteed to be up-to-date and represent best practices for programming in modern Python. The idea is to provide defaults that are so broadly applicable that the majority of users will maintain little if any of their own overrides.
The default behavior is internal management of settings to provide an OOTB experience that works. It is recommended however that you persist the default config file in version control so that other tools like IDEs can utilize your full configuration.
Since Ruff is now provided as a built-in feature, new project templates no longer have such configuration and are much less verbose.
Build improvements¶
Building projects that do not use Hatchling as a backend is now supported and such builds are managed with the standard build tool.
The bridge between Hatch and the Hatchling CLI has been removed. Previously, the builder would send serialized messages to Hatch that would contain the desired content and style for each line of output. This was done in an effort to allow builder and build hook plugins to output pretty messages without actually requiring a dependency like Rich. A problem that arises with this is that builders that invoke subprocesses will not display ANSI codes as one might expect and will lose out on the interactive experience of such invocations, like the built-in binary builder plugin calling cargo build. So now everything is simpler at the expense of no colored output without manual logic, or adding a dependency if you're a third-party plugin.
Faster environment usage¶
Spawning a shell or running commands within environments always first checks that your project's dependencies are satisfied and if not synchronizes the environment with what is defined. Previously, this had the potential to be quite slow for projects that have many dependencies.
Now the set of dependency definitions is hashed and no check is performed if the hash is the same as before, significantly speeding up environment usage in most cases.
Hatchling¶
Hatch now depends on Hatchling v1.19.0, which was also just released.
Better defaults¶
Hatchling is all about providing the best possible defaults, even at the expense of backward compatibility. In this release, there are two breaking changes that provide a much better user experience and were in fact requested by users.
- Both the
force-includeoption and theforce_include_editablewheel build data setting now raise errors if source paths do not exist. - The
wheelbuild target now raises an error when no file inclusion options have been defined and none of its heuristics to determine what to ship are satisfied.
Binary build target¶
A new binary build target is now stable that allows for the building of standalone binaries for projects. This is what Hatch itself uses for its binaries.
Meta¶
Why Hatch?¶
A new page has been introduced that discusses the value proposition of Hatch and Hatchling in comparison to alternatives. Currently, it only addresses a few features but in future this page will become more comprehensive.
Future¶
Upcoming features include a test command, commands to manage dependencies, and workspaces functionality similar to Cargo that will make managing monorepos far easier.
Next year there will be two large efforts that you should expect to see:
-
A significant amount of my free time (and some at work) will be devoted to introducing lock file functionality in Hatch and trying to get whatever that happens to be standardized.
I met with @brettcannon about his thoughts post-PEP 665 and about mousebender. I also met with the prefix.dev team about rip and was fortunate enough to be shown a demo before its official announcement.
At the moment, the two options I see are to either go all in and contribute to mousebender or rely on the Prefix folks and use rip. The latter has the benefit of potentially supporting Conda as a side effect with the downside of being quite new with the spec firmly out of our control. The former has the benefit of being able to easily gain institutional support from the Python packaging team and each of our employers with the downside being a significant amount of work needing to be done.
-
When @henryiii is able to get some free time away from teaching I plan to work with him once again and push very hard for the Python build ecosystem to adopt the extensionlib approach.
I am of the opinion that the Python community has not fully completed the expressed outcome of PEP 517 in that build backends are still (for the most part) reliant on setuptools for building non-Python code bases.
Basically, there are components that interact with compilers to produce extension modules and components that pack files into an archive which we call a build backend. These are two distinct pieces of functionality and my view is that there should be an API that allows backends to consume extension module builders to find out where things got created and where they should be shipped inside archives.
In this hypothetical future any build backend would be able to trigger the building of extension modules based on user configuration.
Support¶
If you or your organization finds value in what Hatch provides, consider a sponsorship to assist with maintenance and more rapid development!
Hatch v1.9.0¶
Hatch v1.9.0 brings improvements to static analysis and important bug fixes.
Static analysis¶
The default version of Ruff has been increased to v0.1.8. This release brings formatting capabilities to docstrings and Hatch enables this by default with line length set to 80. This length was chosen as the default because it plays nicely with the rendering of the most popular themes for Python documentation, such as Material for MkDocs and Furo.
Additionally, it is now possible for projects to pin to specific versions of Ruff for upgrading at a later time:
[tool.hatch.envs.hatch-static-analysis]
+dependencies = ["ruff==X.Y.Z"]
+[envs.hatch-static-analysis]
+dependencies = ["ruff==X.Y.Z"]
+Notable fixes¶
- Python resolution for environments that do not install the project is no longer bound by the project's Python requirement.
- Fixed an edge case for out-of-the-box static analysis when there was existing configuration.
- Compatibility checks for environments no longer occur if the environment is already created. This significantly increases the responsiveness of environment usage.
Hatch v1.10.0¶
Hatch v1.10.0 brings a test command, support for UV, and a Python script runner.
Test command¶
The new test command allows you to easily run tests for your project on multiple versions of Python. The default behavior follows best practices, using pytest with select plugins for test execution and coverage.py for code coverage measurement.
The command is designed to be both simple to use while also satisfying the needs of most projects. For example, the following shows Hatch running tests for Jinja in all environments in the default matrix:
Here is us testing Rich, with a bit of configuration:
See the tutorial for a detailed walk-through and the config reference for options.
UV¶
The package installer UV, brought to you by the same folks behind Ruff, is now supported. In any environment, you can set the installer option to uv to use UV in place of virtualenv & pip for virtual environment creation and dependency management, respectively. This often results in a significant performance benefit.
For example, if you wanted to enable this functionality for the default environment, you could set the following:
[tool.hatch.envs.default]
+installer = "uv"
+[envs.default]
+installer = "uv"
+Semi-internal environments like those used for testing and static analysis have this enabled by default.
See the how-to guide for more information about switching the installer.
Python script runner¶
The run command now supports executing Python scripts with inline metadata as standardized by PEP 723.
As an example, consider the following script:
# /// script
+# requires-python = ">=3.11"
+# dependencies = [
+# "httpx",
+# "rich",
+# ]
+# ///
+
+import httpx
+from rich.pretty import pprint
+
+resp = httpx.get("https://peps.python.org/api/peps.json")
+data = resp.json()
+pprint([(k, v["title"]) for k, v in data.items()][:10])
+If you run the script for the first time as follows:
hatch run script.py
+Hatch will create a dedicated environment for that script using a version of Python greater than or equal to 3.11 with dependencies httpx and rich.
See the how-to guide for more information.
Static analysis¶
The environment used for static analysis is now completely configurable such that you can fully alter the underlying behavior of the fmt command (see the how-to).
Additionally, Ruff has been updated to version 1.4.0 and the rules selected by default have been updated accordingly. Check out their blog post about how the new hand-written parser has made it twice as fast!
Community highlights¶
Visual Studio Code¶
Visual Studio Code announced support for Hatch environments in their latest release. This means that you can now easily discover and select Hatch environments for your projects directly from the editor.
See the how-to guide for detailed instructions.
CMake build plugin¶
A new release of the extension module builder scikit-build-core has introduced a build plugin for Hatchling. This means that you can use Hatchling as your build backend while also shipping extension modules built with CMake.
To get started, add the dependency to your build requirements:
[build-system]
+requires = ["hatchling>=1.24.2", "scikit-build-core~=0.9.3"]
+build-backend = "hatchling.build"
+Then explicitly enable the experimental option (acknowledging that the plugin will move to a dedicated package in the future):
[tool.hatch.build.targets.wheel.hooks.scikit-build]
+experimental = true
+[build.targets.wheel.hooks.scikit-build]
+experimental = true
+At this point, you can create your CMakeLists.txt file as usual and start building your extension modules with CMake! Check out the dedicated example project for a complete demonstration.
Meta¶
Docs¶
The efforts toward documentation improvements have increased substantially and the priorities have shifted. From now on expect to see far more tutorials and how-to guides rather than just reference material.
Future¶
Upcoming features include:
- workspaces functionality similar to Cargo
- commands to manage dependencies
- Windows release artifacts signed by the PSF (just like macOS)
- performance improvements for both the CLI and the Hatchling build system
Support¶
If you or your organization finds value in what Hatch provides, consider a sponsorship to assist with maintenance and more rapid development!
2022¶
Hatch v1.6.0
Hatch v1.6.0 brings improvements to build environments, better handling of dynamic metadata, and support for tools like Visual Studio Code.
2023¶
Hatch v1.9.0
Hatch v1.9.0 brings improvements to static analysis and important bug fixes.
Hatch v1.8.0
Hatch v1.8.0 brings Python distribution management, static analysis and formatting backed by Ruff, and binaries for every platform.
2024¶
Hatch v1.10.0
Hatch v1.10.0 brings a test command, support for UV, and a Python script runner.
Release¶
Hatch v1.10.0
Hatch v1.10.0 brings a test command, support for UV, and a Python script runner.
Hatch v1.9.0
Hatch v1.9.0 brings improvements to static analysis and important bug fixes.
Hatch v1.8.0
Hatch v1.8.0 brings Python distribution management, static analysis and formatting backed by Ruff, and binaries for every platform.
Hatch v1.6.0
Hatch v1.6.0 brings improvements to build environments, better handling of dynamic metadata, and support for tools like Visual Studio Code.
Blog¶
Hatch v1.10.0
Hatch v1.10.0 brings a test command, support for UV, and a Python script runner.
Hatch v1.9.0
Hatch v1.9.0 brings improvements to static analysis and important bug fixes.
Hatch v1.8.0
Hatch v1.8.0 brings Python distribution management, static analysis and formatting backed by Ruff, and binaries for every platform.
Hatch v1.6.0
Hatch v1.6.0 brings improvements to build environments, better handling of dynamic metadata, and support for tools like Visual Studio Code.
Builds¶
Configuration¶
Builds are configured using the tool.hatch.build table. Every target is defined by a section within tool.hatch.build.targets, for example:
[tool.hatch.build.targets.sdist]
+exclude = [
+ "/.github",
+ "/docs",
+]
+
+[tool.hatch.build.targets.wheel]
+packages = ["src/foo"]
+[build.targets.sdist]
+exclude = [
+ "/.github",
+ "/docs",
+]
+
+[build.targets.wheel]
+packages = ["src/foo"]
+Building¶
Invoking the build command without any arguments will build the sdist and wheel targets:
$ hatch build
+[sdist]
+dist/hatch_demo-1rc0.tar.gz
+
+[wheel]
+dist/hatch_demo-1rc0-py3-none-any.whl
+To only build specific targets, use the -t/--target option:
$ hatch build -t wheel
+[wheel]
+dist/hatch_demo-1rc0-py3-none-any.whl
+If the target supports multiple versions, you can specify the exact versions to build by appending a colon followed by the desired versions separated by commas:
$ hatch -v build -t wheel:standard
+[wheel]
+Building `wheel` version `standard`
+dist/hatch_demo-1rc0-py3-none-any.whl
+Packaging ecosystem¶
Hatch complies with modern Python packaging specs and therefore your projects can be used by other tools with Hatch serving as just the build backend.
So you could use tox as an alternative to Hatch's environment management, or cibuildwheel to distribute packages for every platform, and they both will transparently use Hatch without any extra modification.
CLI usage¶
Verbosity¶
The amount of displayed output is controlled solely by the -v/--verbose (environment variable HATCH_VERBOSE) and -q/--quiet (environment variable HATCH_QUIET) root options.
The levels are documented here.
Project awareness¶
No matter the mode, Hatch will always change to the project's root directory for entering or running commands in environments.
Tab completion¶
Completion is achieved by saving a script and then executing it as a part of your shell's startup sequence.
Afterward, you'll need to start a new shell in order for the changes to take effect.
Save the script somewhere:
_HATCH_COMPLETE=bash_source hatch > ~/.hatch-complete.bash
+Source the file in ~/.bashrc (or ~/.bash_profile if on macOS):
. ~/.hatch-complete.bash
+Save the script somewhere:
_HATCH_COMPLETE=zsh_source hatch > ~/.hatch-complete.zsh
+Source the file in ~/.zshrc:
. ~/.hatch-complete.zsh
+Save the script in ~/.config/fish/completions:
_HATCH_COMPLETE=fish_source hatch > ~/.config/fish/completions/hatch.fish
+hatch¶
Usage:
hatch [OPTIONS] COMMAND [ARGS]...
+Options:
| Name | Type | Description | Default |
|---|---|---|---|
--env, -e | text | The name of the environment to use [env var: HATCH_ENV] | default |
--project, -p | text | The name of the project to work on [env var: HATCH_PROJECT] | None |
--verbose, -v | integer range (0 and above) | Increase verbosity (can be used additively) [env var: HATCH_VERBOSE] | 0 |
--quiet, -q | integer range (0 and above) | Decrease verbosity (can be used additively) [env var: HATCH_QUIET] | 0 |
--color / --no-color | boolean | Whether or not to display colored output (default is auto-detection) [env vars: FORCE_COLOR/NO_COLOR] | None |
--interactive / --no-interactive | boolean | Whether or not to allow features like prompts and progress bars (default is auto-detection) [env var: HATCH_INTERACTIVE] | None |
--data-dir | text | The path to a custom directory used to persist data [env var: HATCH_DATA_DIR] | None |
--cache-dir | text | The path to a custom directory used to cache data [env var: HATCH_CACHE_DIR] | None |
--config | text | The path to a custom config file to use [env var: HATCH_CONFIG] | None |
--version | boolean | Show the version and exit. | False |
--help | boolean | Show this message and exit. | False |
hatch build¶
Build a project.
Usage:
hatch build [OPTIONS] [LOCATION]
+Options:
| Name | Type | Description | Default |
|---|---|---|---|
--target, -t | text | The target to build, overriding project defaults. This may be selected multiple times e.g. -t sdist -t wheel | None |
--hooks-only | boolean | Whether or not to only execute build hooks [env var: HATCH_BUILD_HOOKS_ONLY] | False |
--no-hooks | boolean | Whether or not to disable build hooks [env var: HATCH_BUILD_NO_HOOKS] | False |
--ext | boolean | Whether or not to only execute build hooks for distributing binary Python packages, such as compiling extensions. Equivalent to --hooks-only -t wheel | False |
--clean, -c | boolean | Whether or not existing artifacts should first be removed [env var: HATCH_BUILD_CLEAN] | False |
--clean-hooks-after | boolean | Whether or not build hook artifacts should be removed after each build [env var: HATCH_BUILD_CLEAN_HOOKS_AFTER] | False |
--help | boolean | Show this message and exit. | False |
hatch clean¶
Remove build artifacts.
Usage:
hatch clean [OPTIONS] [LOCATION]
+Options:
| Name | Type | Description | Default |
|---|---|---|---|
--target, -t | text | The target with which to remove artifacts, overriding project defaults. This may be selected multiple times e.g. -t sdist -t wheel | None |
--hooks-only | boolean | Whether or not to only remove artifacts from build hooks [env var: HATCH_BUILD_HOOKS_ONLY] | False |
--no-hooks | boolean | Whether or not to ignore artifacts from build hooks [env var: HATCH_BUILD_NO_HOOKS] | False |
--ext | boolean | Whether or not to only remove artifacts from build hooks for distributing binary Python packages, such as compiled extensions. Equivalent to --hooks-only -t wheel | False |
--help | boolean | Show this message and exit. | False |
hatch config¶
Manage the config file
Usage:
hatch config [OPTIONS] COMMAND [ARGS]...
+Options:
| Name | Type | Description | Default |
|---|---|---|---|
--help | boolean | Show this message and exit. | False |
hatch config explore¶
Open the config location in your file manager.
Usage:
hatch config explore [OPTIONS]
+Options:
| Name | Type | Description | Default |
|---|---|---|---|
--help | boolean | Show this message and exit. | False |
hatch config find¶
Show the location of the config file.
Usage:
hatch config find [OPTIONS]
+Options:
| Name | Type | Description | Default |
|---|---|---|---|
--help | boolean | Show this message and exit. | False |
hatch config restore¶
Restore the config file to default settings.
Usage:
hatch config restore [OPTIONS]
+Options:
| Name | Type | Description | Default |
|---|---|---|---|
--help | boolean | Show this message and exit. | False |
hatch config set¶
Assign values to config file entries. If the value is omitted, you will be prompted, with the input hidden if it is sensitive.
Usage:
hatch config set [OPTIONS] KEY [VALUE]
+Options:
| Name | Type | Description | Default |
|---|---|---|---|
--help | boolean | Show this message and exit. | False |
hatch config show¶
Show the contents of the config file.
Usage:
hatch config show [OPTIONS]
+Options:
| Name | Type | Description | Default |
|---|---|---|---|
--all, -a | boolean | Do not scrub secret fields | False |
--help | boolean | Show this message and exit. | False |
hatch config update¶
Update the config file with any new fields.
Usage:
hatch config update [OPTIONS]
+Options:
| Name | Type | Description | Default |
|---|---|---|---|
--help | boolean | Show this message and exit. | False |
hatch dep¶
Manage environment dependencies
Usage:
hatch dep [OPTIONS] COMMAND [ARGS]...
+Options:
| Name | Type | Description | Default |
|---|---|---|---|
--help | boolean | Show this message and exit. | False |
hatch dep hash¶
Output a hash of the currently defined dependencies.
Usage:
hatch dep hash [OPTIONS]
+Options:
| Name | Type | Description | Default |
|---|---|---|---|
--project-only, -p | boolean | Whether or not to exclude environment dependencies | False |
--env-only, -e | boolean | Whether or not to exclude project dependencies | False |
--help | boolean | Show this message and exit. | False |
hatch dep show¶
Display dependencies in various formats
Usage:
hatch dep show [OPTIONS] COMMAND [ARGS]...
+Options:
| Name | Type | Description | Default |
|---|---|---|---|
--help | boolean | Show this message and exit. | False |
hatch dep show requirements¶
Enumerate dependencies as a list of requirements.
Usage:
hatch dep show requirements [OPTIONS]
+Options:
| Name | Type | Description | Default |
|---|---|---|---|
--project-only, -p | boolean | Whether or not to exclude environment dependencies | False |
--env-only, -e | boolean | Whether or not to exclude project dependencies | False |
--feature, -f | text | Whether or not to only show the dependencies of the specified features | None |
--all | boolean | Whether or not to include the dependencies of all features | False |
--help | boolean | Show this message and exit. | False |
hatch dep show table¶
Enumerate dependencies in a tabular format.
Usage:
hatch dep show table [OPTIONS]
+Options:
| Name | Type | Description | Default |
|---|---|---|---|
--project-only, -p | boolean | Whether or not to exclude environment dependencies | False |
--env-only, -e | boolean | Whether or not to exclude project dependencies | False |
--lines, -l | boolean | Whether or not to show lines between table rows | False |
--ascii | boolean | Whether or not to only use ASCII characters | False |
--help | boolean | Show this message and exit. | False |
hatch env¶
Manage project environments
Usage:
hatch env [OPTIONS] COMMAND [ARGS]...
+Options:
| Name | Type | Description | Default |
|---|---|---|---|
--help | boolean | Show this message and exit. | False |
hatch env create¶
Create environments.
Usage:
hatch env create [OPTIONS] [ENV_NAME]
+Options:
| Name | Type | Description | Default |
|---|---|---|---|
--help | boolean | Show this message and exit. | False |
hatch env find¶
Locate environments.
Usage:
hatch env find [OPTIONS] [ENV_NAME]
+Options:
| Name | Type | Description | Default |
|---|---|---|---|
--help | boolean | Show this message and exit. | False |
hatch env prune¶
Remove all environments.
Usage:
hatch env prune [OPTIONS]
+Options:
| Name | Type | Description | Default |
|---|---|---|---|
--help | boolean | Show this message and exit. | False |
hatch env remove¶
Remove environments.
Usage:
hatch env remove [OPTIONS] [ENV_NAME]
+Options:
| Name | Type | Description | Default |
|---|---|---|---|
--help | boolean | Show this message and exit. | False |
hatch env run¶
Run commands within project environments.
The -e/--env option overrides the equivalent root option and the HATCH_ENV environment variable.
The -i/--include and -x/--exclude options may be used to include or exclude certain variables, optionally followed by specific comma-separated values, and may be selected multiple times. For example, if you have the following configuration:
[[tool.hatch.envs.test.matrix]]
+python = ["3.9", "3.10"]
+version = ["42", "3.14", "9000"]
+[[envs.test.matrix]]
+python = ["3.9", "3.10"]
+version = ["42", "3.14", "9000"]
+then running:
hatch env run -i py=3.10 -x version=9000 test:pytest
+would execute pytest in the environments test.py3.10-42 and test.py3.10-3.14. Note that py may be used as an alias for python.
Note
The inclusion option is treated as an intersection while the exclusion option is treated as a union i.e. an environment must match all of the included variables to be selected while matching any of the excluded variables will prevent selection.
Usage:
hatch env run [OPTIONS] ARGS...
+Options:
| Name | Type | Description | Default |
|---|---|---|---|
--env, -e | text | The environments to target | None |
--include, -i | text | The matrix variables to include | None |
--exclude, -x | text | The matrix variables to exclude | None |
--filter, -f | text | The JSON data used to select environments | None |
--force-continue | boolean | Run every command and if there were any errors exit with the first code | False |
--ignore-compat | boolean | Ignore incompatibility when selecting specific environments | False |
--help | boolean | Show this message and exit. | False |
hatch env show¶
Show the available environments.
Usage:
hatch env show [OPTIONS] [ENVS]...
+Options:
| Name | Type | Description | Default |
|---|---|---|---|
--ascii | boolean | Whether or not to only use ASCII characters | False |
--json | boolean | Whether or not to output in JSON format | False |
--internal, -i | boolean | Show internal environments | False |
--help | boolean | Show this message and exit. | False |
hatch fmt¶
Format and lint source code.
Usage:
hatch fmt [OPTIONS] [ARGS]...
+Options:
| Name | Type | Description | Default |
|---|---|---|---|
--check | boolean | Only check for errors rather than fixing them | False |
--linter, -l | boolean | Only run the linter | False |
--formatter, -f | boolean | Only run the formatter | False |
--sync | boolean | Sync the default config file with the current version of Hatch | False |
--help | boolean | Show this message and exit. | False |
hatch new¶
Create or initialize a project.
Usage:
hatch new [OPTIONS] [NAME] [LOCATION]
+Options:
| Name | Type | Description | Default |
|---|---|---|---|
--interactive, -i | boolean | Interactively choose details about the project | False |
--cli | boolean | Give the project a command line interface | False |
--init | boolean | Initialize an existing project | False |
--help | boolean | Show this message and exit. | False |
hatch project¶
View project information
Usage:
hatch project [OPTIONS] COMMAND [ARGS]...
+Options:
| Name | Type | Description | Default |
|---|---|---|---|
--help | boolean | Show this message and exit. | False |
hatch project metadata¶
Display project metadata.
If you want to view the raw readme file without rendering, you can use a JSON parser like jq:
hatch project metadata | jq -r .readme
+Usage:
hatch project metadata [OPTIONS] [FIELD]
+Options:
| Name | Type | Description | Default |
|---|---|---|---|
--help | boolean | Show this message and exit. | False |
hatch publish¶
Publish build artifacts.
Usage:
hatch publish [OPTIONS] [ARTIFACTS]...
+Options:
| Name | Type | Description | Default |
|---|---|---|---|
--repo, -r | text | The repository with which to publish artifacts [env var: HATCH_INDEX_REPO] | None |
--user, -u | text | The user with which to authenticate [env var: HATCH_INDEX_USER] | None |
--auth, -a | text | The credentials to use for authentication [env var: HATCH_INDEX_AUTH] | None |
--ca-cert | text | The path to a CA bundle [env var: HATCH_INDEX_CA_CERT] | None |
--client-cert | text | The path to a client certificate, optionally containing the private key [env var: HATCH_INDEX_CLIENT_CERT] | None |
--client-key | text | The path to the client certificate's private key [env var: HATCH_INDEX_CLIENT_KEY] | None |
--no-prompt, -n | boolean | Disable prompts, such as for missing required fields | False |
--initialize-auth | boolean | Save first-time authentication information even if nothing was published | False |
--publisher, -p | text | The publisher plugin to use (default is index) [env var: HATCH_PUBLISHER] | index |
--option, -o | text | Options to pass to the publisher plugin. This may be selected multiple times e.g. -o foo=bar -o baz=23 [env var: HATCH_PUBLISHER_OPTIONS] | None |
--yes, -y | boolean | Confirm without prompting when the plugin is disabled | False |
--help | boolean | Show this message and exit. | False |
hatch python¶
Manage Python installations
Usage:
hatch python [OPTIONS] COMMAND [ARGS]...
+Options:
| Name | Type | Description | Default |
|---|---|---|---|
--help | boolean | Show this message and exit. | False |
hatch python find¶
Locate Python binaries.
Usage:
hatch python find [OPTIONS] NAME
+Options:
| Name | Type | Description | Default |
|---|---|---|---|
-p, --parent | boolean | Show the parent directory of the Python binary | False |
--dir, -d | text | The directory in which distributions reside | None |
--help | boolean | Show this message and exit. | False |
hatch python install¶
Install Python distributions.
You may select all to install all compatible distributions:
hatch python install all
+You can set custom sources for distributions by setting the HATCH_PYTHON_SOURCE_<NAME> environment variable where <NAME> is the uppercased version of the distribution name with periods replaced by underscores e.g. HATCH_PYTHON_SOURCE_PYPY3_10.
Usage:
hatch python install [OPTIONS] NAMES...
+Options:
| Name | Type | Description | Default |
|---|---|---|---|
--private | boolean | Do not add distributions to the user PATH | False |
--update, -u | boolean | Update existing installations | False |
--dir, -d | text | The directory in which to install distributions, overriding configuration | None |
--help | boolean | Show this message and exit. | False |
hatch python remove¶
Remove Python distributions.
You may select all to remove all installed distributions:
hatch python remove all
+Usage:
hatch python remove [OPTIONS] NAMES...
+Options:
| Name | Type | Description | Default |
|---|---|---|---|
--dir, -d | text | The directory in which distributions reside | None |
--help | boolean | Show this message and exit. | False |
hatch python show¶
Show the available Python distributions.
Usage:
hatch python show [OPTIONS]
+Options:
| Name | Type | Description | Default |
|---|---|---|---|
--ascii | boolean | Whether or not to only use ASCII characters | False |
--dir, -d | text | The directory in which distributions reside | None |
--help | boolean | Show this message and exit. | False |
hatch python update¶
Update Python distributions.
You may select all to update all installed distributions:
hatch python update all
+Usage:
hatch python update [OPTIONS] NAMES...
+Options:
| Name | Type | Description | Default |
|---|---|---|---|
--dir, -d | text | The directory in which distributions reside | None |
--help | boolean | Show this message and exit. | False |
hatch run¶
Run commands within project environments. This is a convenience wrapper around the env run command.
If the first argument contains a colon, then the preceding component will be interpreted as the name of the environment to target, overriding the -e/--env root option and the HATCH_ENV environment variable.
If the environment provides matrices, then you may also provide leading arguments starting with a + or - to select or exclude certain variables, optionally followed by specific comma-separated values. For example, if you have the following configuration:
[[tool.hatch.envs.test.matrix]]
+python = ["3.9", "3.10"]
+version = ["42", "3.14", "9000"]
+[[envs.test.matrix]]
+python = ["3.9", "3.10"]
+version = ["42", "3.14", "9000"]
+then running:
hatch run +py=3.10 -version=9000 test:pytest
+would execute pytest in the environments test.py3.10-42 and test.py3.10-3.14. Note that py may be used as an alias for python.
Note
Inclusions are treated as an intersection while exclusions are treated as a union i.e. an environment must match all of the included variables to be selected while matching any of the excluded variables will prevent selection.
Usage:
hatch run [OPTIONS] [ENV:]ARGS...
+Options:
| Name | Type | Description | Default |
|---|---|---|---|
--help | boolean | Show this message and exit. | False |
hatch self¶
Manage Hatch
Usage:
hatch self [OPTIONS] COMMAND [ARGS]...
+Options:
| Name | Type | Description | Default |
|---|---|---|---|
--help | boolean | Show this message and exit. | False |
hatch self report¶
Generate a pre-populated GitHub issue.
Usage:
hatch self report [OPTIONS]
+Options:
| Name | Type | Description | Default |
|---|---|---|---|
--no-open, -n | boolean | Show the URL instead of opening it | False |
--help | boolean | Show this message and exit. | False |
hatch self restore¶
Restore the installation
Usage:
hatch self restore [OPTIONS] [ARGS]...
+Options:
| Name | Type | Description | Default |
|---|---|---|---|
--help | boolean | Show this message and exit. | False |
hatch self update¶
Install the latest version
Usage:
hatch self update [OPTIONS] [ARGS]...
+Options:
| Name | Type | Description | Default |
|---|---|---|---|
--help | boolean | Show this message and exit. | False |
hatch shell¶
Enter a shell within a project's environment.
Usage:
hatch shell [OPTIONS] [ENV_NAME]
+Options:
| Name | Type | Description | Default |
|---|---|---|---|
--name | text | N/A | None |
--path | text | N/A | None |
--help | boolean | Show this message and exit. | False |
hatch status¶
Show information about the current environment.
Usage:
hatch status [OPTIONS]
+Options:
| Name | Type | Description | Default |
|---|---|---|---|
--help | boolean | Show this message and exit. | False |
hatch test¶
Run tests using the hatch-test environment matrix.
If no filtering options are selected, then tests will be run in the first compatible environment found in the matrix with priority given to those matching the current interpreter.
The -i/--include and -x/--exclude options may be used to include or exclude certain variables, optionally followed by specific comma-separated values, and may be selected multiple times. For example, if you have the following configuration:
[[tool.hatch.envs.hatch-test.matrix]]
+python = ["3.9", "3.10"]
+version = ["42", "3.14", "9000"]
+[[envs.hatch-test.matrix]]
+python = ["3.9", "3.10"]
+version = ["42", "3.14", "9000"]
+then running:
hatch test -i py=3.10 -x version=9000
+would run tests in the environments hatch-test.py3.10-42 and hatch-test.py3.10-3.14.
The -py/--python option is a shortcut for specifying the inclusion -i py=....
Note
The inclusion option is treated as an intersection while the exclusion option is treated as a union i.e. an environment must match all of the included variables to be selected while matching any of the excluded variables will prevent selection.
Usage:
hatch test [OPTIONS] [ARGS]...
+Options:
| Name | Type | Description | Default |
|---|---|---|---|
--randomize, -r | boolean | Randomize the order of test execution | False |
--parallel, -p | boolean | Parallelize test execution | False |
--retries | integer | Number of times to retry failed tests | None |
--retry-delay | float | Seconds to wait between retries | None |
--cover, -c | boolean | Measure code coverage | False |
--cover-quiet | boolean | Disable coverage reporting after tests, implicitly enabling --cover | False |
--all, -a | boolean | Test all environments in the matrix | False |
--python, -py | text | The Python versions to test, equivalent to: -i py=... | None |
--include, -i | text | The matrix variables to include | None |
--exclude, -x | text | The matrix variables to exclude | None |
--show, -s | boolean | Show information about environments in the matrix | False |
--help | boolean | Show this message and exit. | False |
hatch version¶
View or set a project's version.
Usage:
hatch version [OPTIONS] [DESIRED_VERSION]
+Options:
| Name | Type | Description | Default |
|---|---|---|---|
--help | boolean | Show this message and exit. | False |
Contributing¶
The usual process to make a contribution is to:
- Check for existing related issues
- Fork the repository and create a new branch
- Make your changes
- Make sure formatting, linting and tests passes.
- Add tests if possible to cover the lines you added.
- Commit, and send a Pull Request.
Clone the repository¶
Clone the hatch repository, cd into it, and create a new branch for your contribution:
cd hatch
+git checkout -b add-my-contribution
+Run the tests¶
Run the test suite while developing:
hatch run dev
+Run the test suite with coverage report:
hatch run cov
+Run the extended test suite with coverage:
hatch run full
+Lint¶
Run automated formatting:
hatch run lint:fmt
+Run full linting and type checking:
hatch run lint:all
+Docs¶
Start the documentation in development:
hatch run docs:serve
+Build and validate the documentation website:
hatch run docs:build-check
+Community highlights¶
Integration¶
- Project Jupyter - https://blog.jupyter.org/packaging-for-jupyter-in-2022-c7be64c38926
- Visual Studio Code - https://code.visualstudio.com/updates/v1_88#_hatch-environment-discovery
Adoption¶
Users¶
The following is not intended to be a complete enumeration. Be sure to view the development version of this page for an up-to-date listing.
Projects¶
aiogram | Apache Airflow | argon2-cffi | attrs | Black | coffea | Colorama | Django Anymail | Django Debug Toolbar | Django NYT | Django OTP | Django OTP Agents | Django OTP Twilio | Django OTP YubiKey | Django Places | Django Wiki | FastAPI | filelock | Fluentd | github3.py | Gradio | HTTPX | iCalendar for Humans | LinkChecker | Litestar | Material for MkDocs | MicroPython | MkDocs | openSUSE | Nox | Packit | pipx | platformdirs | Pydantic | Pygments | PyHamcrest | PyMdown Extensions | Python JSON Schema | Rye | SALib | Spack | Starlette | structlog | tox | Twisted | urllib3 | Uvicorn | virtualenv | Voilà | XGBoost | Ypy | yt-dlp
Industry¶
- Anaconda [1|2|3|4|5|6|7]
- Airbnb [1]
- Astronomer [1|2|3]
- Bitwarden [1]
- Bloomberg [1|2]
- Blue Robotics [1]
- Cars.com [1]
- Cisco [1|2]
- Databricks [1|2|3]
- Datadog [1|2|3|4]
- deepset [1|2]
- Elastic [1|2|3]
- Google [1|2|3|4|5|6]
- IBM [1]
- JPMorgan Chase [1]
- Intel Corporation [1|2|3]
- McKinsey [1|2]
- Meta [1|2|3]
- Microsoft [1|2|3|4|5|6]
- OpenAI [1]
- Oracle [1]
- Palo Alto Networks [1]
- Quansight [1]
- Red Hat [1|2|3|4|5]
- Salesforce [1]
- Snowflake [1]
- Splunk [1]
- The Westervelt Company [1|2|3|4|5|6]
- Virtru [1|2]
- VMware [1|2|3]
- Volvo Group [1]
Organizations¶
- Free Ebook Foundation [1]
- Greater Paris University Hospitals (AP-HP) [1]
- Massachusetts General Hospital [1]
- Let's Encrypt [1]
- Max Planck Society [1]
- OpenTelemetry [1|2]
- Smithsonian Institution [1]
- The New York Public Library [1]
Government¶
Academia¶
- Brown University
- Carnegie Mellon University
- Chinese Academy of Sciences
- Georgia Institute of Technology
- Harvard University
- Heidelberg University
- Leiden University
- Maastricht University
- Massachusetts Institute of Technology
- Medical University of Innsbruck
- Polytechnique Montréal
- Siberian Branch of the Russian Academy of Sciences
- Stanford University
- University of British Columbia
- University of California, Berkeley
- University of California, Santa Barbara
- University of Freiburg
- University of Illinois Urbana-Champaign
- University of Lausanne
- University of Ljubljana
- University of Massachusetts Amherst
- University of Oxford
- University of Pennsylvania
- University of Regensburg
- University of Sussex
- University of Toronto Scarborough
- utsc-networking [1|2|3|4]
- University of Washington
- University of Wisconsin-Madison
- Waseda University
- Wellcome Sanger Institute [1]
Research¶
- Clariah [1]
- CloudDrift [1]
- Dask [1|2]
- GAMA [1]
- IPython [1|2|3]
- MNE [1|2|3]
- NIPY [1|2]
- Project Jupyter
- RAPIDS [1]
- Scikit-HEP [1|2|3|4|5|6|7|8|9|10]
- scverse [1|2|3]
- Spyder [1]
Security¶
Crypto¶
Build configuration¶
Build targets are defined as sections within tool.hatch.build.targets:
[tool.hatch.build.targets.<TARGET_NAME>]
+[build.targets.<TARGET_NAME>]
+Tip
Although not recommended, you may define global configuration in the tool.hatch.build table. Keys may then be overridden by target config.
Build system¶
To be compatible with the broader Python packaging ecosystem, you must define the build system as follows:
[build-system]
+requires = ["hatchling"]
+build-backend = "hatchling.build"
+The version of hatchling defined here will be used to build all targets.
Hatchling is a standards-compliant1 build backend and is a dependency of Hatch itself.
File selection¶
VCS¶
By default, Hatch will respect the first .gitignore or .hgignore file found in your project's root directory or parent directories. Set ignore-vcs to true to disable this behavior:
[tool.hatch.build.targets.sdist]
+ignore-vcs = true
+[build.targets.sdist]
+ignore-vcs = true
+Note
For .hgignore files only glob syntax is supported.
Patterns¶
You can set the include and exclude options to select exactly which files will be shipped in each build, with exclude taking precedence. Every entry represents a Git-style glob pattern.
For example, the following configuration:
[tool.hatch.build.targets.sdist]
+include = [
+ "pkg/*.py",
+ "/tests",
+]
+exclude = [
+ "*.json",
+ "pkg/_compat.py",
+]
+[build.targets.sdist]
+include = [
+ "pkg/*.py",
+ "/tests",
+]
+exclude = [
+ "*.json",
+ "pkg/_compat.py",
+]
+will exclude every file with a .json extension, and will include everything under a tests directory located at the root and every file with a .py extension that is directly under a pkg directory located at the root except for _compat.py.
Artifacts¶
If you want to include files that are ignored by your VCS, such as those that might be created by build hooks, you can use the artifacts option. This option is semantically equivalent to include.
Note that artifacts are not affected by the exclude option. Artifacts can be excluded by using more explicit paths or by using the ! negation operator. When using the ! operator, the negated pattern(s) must come after the more generic ones.
[tool.hatch.build.targets.wheel]
+artifacts = [
+ "*.so",
+ "*.dll",
+ "!/foo/*.so",
+]
+[build.targets.wheel]
+artifacts = [
+ "*.so",
+ "*.dll",
+ "!/foo/*.so",
+]
+Explicit selection¶
Generic¶
You can use the only-include option to prevent directory traversal starting at the project root and only select specific relative paths to directories or files. Using this option ignores any defined include patterns.
[tool.hatch.build.targets.sdist]
+only-include = ["pkg", "tests/unit"]
+[build.targets.sdist]
+only-include = ["pkg", "tests/unit"]
+Packages¶
The packages option is semantically equivalent to only-include (which takes precedence) except that the shipped path will be collapsed to only include the final component.
So for example, if you want to ship a package foo that is stored in a directory src you would do:
[tool.hatch.build.targets.wheel]
+packages = ["src/foo"]
+[build.targets.wheel]
+packages = ["src/foo"]
+Forced inclusion¶
The force-include option allows you to select specific files or directories from anywhere on the file system that should be included and map them to the desired relative distribution path.
For example, if there was a directory alongside the project root named artifacts containing a file named lib.so and a file named lib.h in your home directory, you could ship both files in a pkg directory with the following configuration:
[tool.hatch.build.targets.wheel.force-include]
+"../artifacts" = "pkg"
+"~/lib.h" = "pkg/lib.h"
+[build.targets.wheel.force-include]
+"../artifacts" = "pkg"
+"~/lib.h" = "pkg/lib.h"
+Note
- Files must be mapped exactly to their desired paths, not to directories.
- The contents of directory sources are recursively included.
- To map directory contents directly to the root use
/(a forward slash). - Sources that do not exist will raise an error.
Warning
Files included using this option will overwrite any file path that was already included by other file selection options.
Default file selection¶
If no file selection options are provided, then what gets included is determined by each build target.
Excluding files outside packages¶
If you want to exclude non-artifact files that do not reside within a Python package, set only-packages to true:
[tool.hatch.build.targets.wheel]
+only-packages = true
+[build.targets.wheel]
+only-packages = true
+Rewriting paths¶
You can rewrite relative paths to directories with the sources option. For example, the following configuration:
[tool.hatch.build.targets.wheel.sources]
+"src/foo" = "bar"
+[build.targets.wheel.sources]
+"src/foo" = "bar"
+would distribute the file src/foo/file.ext as bar/file.ext.
If you want to remove path prefixes entirely, rather than setting each to an empty string, you can define sources as an array:
[tool.hatch.build.targets.wheel]
+sources = ["src"]
+[build.targets.wheel]
+sources = ["src"]
+If you want to add a prefix to paths, you can use an empty string. For example, the following configuration:
[tool.hatch.build.targets.wheel.sources]
+"" = "foo"
+[build.targets.wheel.sources]
+"" = "foo"
+would distribute the file bar/file.ext as foo/bar/file.ext.
The packages option itself relies on sources. Defining packages = ["src/foo"] for the wheel target is equivalent to the following:
[tool.hatch.build.targets.wheel]
+only-include = ["src/foo"]
+sources = ["src"]
+[build.targets.wheel]
+only-include = ["src/foo"]
+sources = ["src"]
+Performance¶
All encountered directories are traversed by default. To skip non-artifact directories that are excluded, set skip-excluded-dirs to true:
[tool.hatch.build]
+skip-excluded-dirs = true
+[build]
+skip-excluded-dirs = true
+Warning
This may result in not shipping desired files. For example, if you want to include the file a/b/c.txt but your VCS ignores a/b, the file c.txt will not be seen because its parent directory will not be entered. In such cases you can use the force-include option.
Reproducible builds¶
By default, build targets will build in a reproducible manner provided that they support that behavior. To disable this, set reproducible to false:
[tool.hatch.build]
+reproducible = false
+[build]
+reproducible = false
+When enabled, the SOURCE_DATE_EPOCH environment variable will be used for all build timestamps. If not set, then Hatch will use an unchanging default value.
Output directory¶
When the output directory is not provided to the build command, the dist directory will be used by default. You can change the default to a different directory using a relative or absolute path like so:
[tool.hatch.build]
+directory = "<PATH>"
+[build]
+directory = "<PATH>"
+Dev mode¶
By default for dev mode environment installations or editable installs, the wheel target will determine which directories should be added to Python's search path based on the selected files.
If you want to override this detection or perhaps instruct other build targets as well, you can use the dev-mode-dirs option:
[tool.hatch.build]
+dev-mode-dirs = ["."]
+[build]
+dev-mode-dirs = ["."]
+If you don't want to add entire directories to Python's search path, you can enable a more targeted mechanism with the mutually exclusive dev-mode-exact option:
[tool.hatch.build]
+dev-mode-exact = true
+[build]
+dev-mode-exact = true
+Warning
The dev-mode-exact mechanism is not supported by static analysis tools & IDEs, therefore functionality such as autocompletion is unlikely to work.
Build targets¶
A build target can be provided by any builder plugin. There are three built-in build targets: wheel, sdist, and custom.
Dependencies¶
You can specify additional dependencies that will be installed in each build environment, such as for third party builders:
[tool.hatch.build.targets.your-target-name]
+dependencies = [
+ "your-builder-plugin"
+]
+[build.targets.your-target-name]
+dependencies = [
+ "your-builder-plugin"
+]
+You can also declare dependence on the project's runtime dependencies with the require-runtime-dependencies option:
[tool.hatch.build.targets.your-target-name]
+require-runtime-dependencies = true
+[build.targets.your-target-name]
+require-runtime-dependencies = true
+Additionally, you may declare dependence on specific runtime features of the project with the require-runtime-features option:
[tool.hatch.build.targets.your-target-name]
+require-runtime-features = [
+ "feature1",
+ "feature2",
+]
+[build.targets.your-target-name]
+require-runtime-features = [
+ "feature1",
+ "feature2",
+]
+Versions¶
If a build target supports multiple build strategies or if there are major changes over time, you can specify exactly which versions you want to build using the versions option:
[tool.hatch.build.targets.<TARGET_NAME>]
+versions = [
+ "v1",
+ "beta-feature",
+]
+[build.targets.<TARGET_NAME>]
+versions = [
+ "v1",
+ "beta-feature",
+]
+See the wheel target for a real world example.
Build hooks¶
A build hook defines code that will be executed at various stages of the build process and can be provided by any build hook plugin. There is one built-in build hook: custom.
Build hooks can be applied either globally:
[tool.hatch.build.hooks.<HOOK_NAME>]
+[build.hooks.<HOOK_NAME>]
+or to specific build targets:
[tool.hatch.build.targets.<TARGET_NAME>.hooks.<HOOK_NAME>]
+[build.targets.<TARGET_NAME>.hooks.<HOOK_NAME>]
+Dependencies¶
You can specify additional dependencies that will be installed in each build environment, such as for third party build hooks:
[tool.hatch.build.hooks.your-hook-name]
+dependencies = [
+ "your-build-hook-plugin"
+]
+[build.hooks.your-hook-name]
+dependencies = [
+ "your-build-hook-plugin"
+]
+You can also declare dependence on the project's runtime dependencies with the require-runtime-dependencies option:
[tool.hatch.build.hooks.your-hook-name]
+require-runtime-dependencies = true
+[build.hooks.your-hook-name]
+require-runtime-dependencies = true
+Additionally, you may declare dependence on specific runtime features of the project with the require-runtime-features option:
[tool.hatch.build.hooks.your-hook-name]
+require-runtime-features = [
+ "feature1",
+ "feature2",
+]
+[build.hooks.your-hook-name]
+require-runtime-features = [
+ "feature1",
+ "feature2",
+]
+Order of execution¶
For each build target, build hooks execute in the order in which they are defined, starting with global hooks.
As an example, for the following configuration:
[tool.hatch.build.targets.foo.hooks.hook2]
+
+[tool.hatch.build.hooks.hook3]
+[tool.hatch.build.hooks.hook1]
+[build.targets.foo.hooks.hook2]
+
+[build.hooks.hook3]
+[build.hooks.hook1]
+When target foo is built, build hook hook3 will be executed first, followed by hook1, and then finally hook2.
Conditional execution¶
If you want to disable a build hook by default and control its use by environment variables, you can do so by setting the enable-by-default option to false:
[tool.hatch.build.hooks.<HOOK_NAME>]
+enable-by-default = false
+[build.hooks.<HOOK_NAME>]
+enable-by-default = false
+Environment variables¶
| Variable | Default | Description |
|---|---|---|
HATCH_BUILD_CLEAN | false | Whether or not existing artifacts should first be removed |
HATCH_BUILD_CLEAN_HOOKS_AFTER | false | Whether or not build hook artifacts should be removed after each build |
HATCH_BUILD_HOOKS_ONLY | false | Whether or not to only execute build hooks |
HATCH_BUILD_NO_HOOKS | false | Whether or not to disable all build hooks; this takes precedence over other options |
HATCH_BUILD_HOOKS_ENABLE | false | Whether or not to enable all build hooks |
HATCH_BUILD_HOOK_ENABLE_<HOOK_NAME> | false | Whether or not to enable the build hook named <HOOK_NAME> |
HATCH_BUILD_LOCATION | dist | The location with which to build the targets; only used by the build command |
Context formatting¶
You can populate configuration with the values of certain supported fields using the syntax of Python's format strings. Each field interprets the modifier part after the colon differently, if at all.
Global fields¶
Any configuration that declares support for context formatting will always support these fields.
Paths¶
| Field | Description |
|---|---|
root | The root project directory |
home | The user's home directory |
All paths support the following modifiers:
| Modifier | Description |
|---|---|
uri | The normalized absolute URI path prefixed by file: |
real | The path with all symbolic links resolved |
parent | The parent of the preceding path |
Tip
The parent modifier can be chained and may be combined with either the uri or real modifier, with the latter placed at the end. For example:
[tool.hatch.envs.test]
+dependencies = [
+ "example-project @ {root:parent:parent:uri}/example-project",
+]
+[envs.test]
+dependencies = [
+ "example-project @ {root:parent:parent:uri}/example-project",
+]
+System separators¶
| Field | Description |
|---|---|
/ | \ on Windows, / otherwise |
; | ; on Windows, : otherwise |
Environment variables¶
The env field and its modifier allow you to select the value of an environment variable. If the environment variable is not set, you must specify a default value as an additional modifier e.g. {env:PATH:DEFAULT}.
Field nesting¶
You can insert fields within others. For example, if you wanted a script that displays the value of the environment variable FOO, with a fallback to the environment variable BAR, with its own fallback to the user's home directory, you could do the following:
[tool.hatch.envs.test.scripts]
+display = "echo {env:FOO:{env:BAR:{home}}}"
+[envs.test.scripts]
+display = "echo {env:FOO:{env:BAR:{home}}}"
+Dependency configuration¶
Project dependencies are defined with PEP 508 strings using optional PEP 440 version specifiers.
Version specifiers¶
A version specifier consists of a series of version clauses, separated by commas. For example:
[project]
+...
+dependencies = [
+ "cryptography",
+ "click>=7, <9, != 8.0.0",
+ "python-dateutil==2.8.*",
+ "numpy~=1.21.4",
+]
+The comma is equivalent to a logical AND operator: a candidate version must match all given version clauses in order to match the specifier as a whole.
Operators¶
| Operators | Function |
|---|---|
~= | Compatible release |
== | Version matching |
!= | Version exclusion |
<=, >= | Inclusive ordered comparison |
<, > | Exclusive ordered comparison |
=== | Arbitrary equality |
Version matching¶
A version matching clause includes the version matching operator == and a version identifier.
By default, the version matching operator is based on a strict equality comparison: the specified version must be exactly the same as the requested version.
| Clause | Allowed versions |
|---|---|
==1 | 1.0.0 |
==1.2 | 1.2.0 |
Prefix matching may be requested instead of strict comparison, by appending a trailing .* to the version identifier in the version matching clause. This means that additional trailing segments will be ignored when determining whether or not a version identifier matches the clause.
| Clause | Allowed versions |
|---|---|
==1.* | >=1.0.0, <2.0.0 |
==1.2.* | >=1.2.0, <1.3.0 |
Compatible release¶
A compatible release clause consists of the compatible release operator ~= and a version identifier. It matches any candidate version that is expected to be compatible with the specified version.
For a given release identifier V.N, the compatible release clause is approximately equivalent to the following pair of comparison clauses:
>= V.N, == V.*
+This operator cannot be used with a single segment version number such as ~=1.
| Clause | Allowed versions |
|---|---|
~=1.2 | >=1.2.0, <2.0.0 |
~=1.2.3 | >=1.2.3, <1.3.0 |
Version exclusion¶
A version exclusion clause includes the version exclusion operator != and a version identifier.
The allowed version identifiers and comparison semantics are the same as those of the Version matching operator, except that the sense of any match is inverted.
Ordered comparison¶
Inclusive comparisons allow for the version identifier part of clauses whereas exclusive comparisons do not. For example, >=1.2 allows for version 1.2.0 while >1.2 does not.
Unlike the inclusive ordered comparisons <= and >=, the exclusive ordered comparisons < and > specifically exclude pre-releases, post-releases, and local versions of the specified version.
Arbitrary equality¶
Though heavily discouraged, arbitrary equality comparisons allow for simple string matching without any version semantics, for example ===foobar.
Environment markers¶
Environment markers allow for dependencies to only be installed when certain conditions are met.
For example, if you need to install the latest version of cryptography that is available for a given Python major version you could define the following:
cryptography==3.3.2; python_version < "3"
+cryptography>=35.0; python_version > "3"
+Alternatively, if you only need it on Python 3 when running on Windows you could do:
cryptography; python_version ~= "3.0" and platform_system == "Windows"
+The available environment markers are as follows.
| Marker | Python equivalent | Examples |
|---|---|---|
os_name | import osos.name |
|
sys_platform | import syssys.platform |
|
platform_machine | import platformplatform.machine() |
|
platform_python_implementation | import platformplatform.python_implementation() |
|
platform_release | import platformplatform.release() |
|
platform_system | import platformplatform.system() |
|
platform_version | import platformplatform.version() |
|
python_version | import platform'.'.join(platform.python_version_tuple()[:2]) |
|
python_full_version | import platformplatform.python_version() |
|
implementation_name | import syssys.implementation.name |
|
implementation_version | See here |
|
Features¶
You can select groups of optional dependencies to install using the extras syntax. For example, if a dependency named foo defined the following:
[project.optional-dependencies]
+crypto = [
+ "PyJWT",
+ "cryptography",
+]
+fastjson = [
+ "orjson",
+]
+cli = [
+ "prompt-toolkit",
+ "colorama; platform_system == 'Windows'",
+]
+You can select the cli and crypto features like so:
foo[cli,crypto]==1.*
+Note that the features come immediately after the package name, before any version specifiers.
Self-referential¶
Feature groups can self-referentially extend others. For example, for a project called awesome-project, the dev feature group in the following pyproject.toml file would select everything in the crypto feature group, plus black:
[project]
+name = "awesome-project"
+
+[project.optional-dependencies]
+crypto = [
+ "PyJWT",
+ "cryptography",
+]
+dev = [
+ "awesome-project[crypto]",
+ "black",
+]
+Direct references¶
Instead of using normal version specifiers and fetching packages from an index like PyPI, you can define exact sources using direct references with an explicit URI.
Direct references are usually not meant to be used for dependencies of a published project but rather are used for defining dependencies for an environment.
All direct reference types are prefixed by the package name like:
<NAME> @ <REFERENCE>
+Version control systems¶
Various version control systems (VCS) are supported as long as the associated executable is available along your PATH.
VCS direct references are defined using one of the following formats:
<NAME> @ <SCHEME>://<PATH>
+<NAME> @ <SCHEME>://<PATH>@<REVISION>
+You may also append a #subdirectory=<PATH> component for specifying the relative path to the Python package when it is not located at the root e.g. #subdirectory=lib/foo.
For more information, refer to this.
Supported VCS¶
| Executable | Schemes | Revisions | Example |
|---|---|---|---|
git |
|
| proj @ git+https://github.com/org/proj.git@v1 |
| Executable | Schemes | Revisions | Example |
|---|---|---|---|
hg |
|
| proj @ hg+file:///path/to/proj@v1 |
| Executable | Schemes | Revisions | Example |
|---|---|---|---|
svn |
|
| proj @ svn+file:///path/to/proj |
| Executable | Schemes | Revisions | Example |
|---|---|---|---|
bzr |
|
| proj @ bzr+lp:proj@v1 |
Local¶
You can install local packages with the file scheme in the following format:
<NAME> @ file://<HOST>/<PATH>
+The <HOST> is only used on Windows systems, where it can refer to a network share. If omitted it is assumed to be localhost and the third slash must still be present.
The <PATH> can refer to a source archive, a wheel, or a directory containing a Python package.
| Type | Unix | Windows |
|---|---|---|
| Source archive | proj @ file:///path/to/pkg.tar.gz | proj @ file:///c:/path/to/pkg.tar.gz |
| Wheel | proj @ file:///path/to/pkg.whl | proj @ file:///c:/path/to/pkg.whl |
| Directory | proj @ file:///path/to/pkg | proj @ file:///c:/path/to/pkg |
Tip
You may also specify paths relative to your project's root directory on all platforms by using context formatting:
<NAME> @ {root:uri}/pkg_inside_project
+<NAME> @ {root:parent:uri}/pkg_alongside_project
+Remote¶
You can install source archives and wheels by simply referring to a URL:
black @ https://github.com/psf/black/archive/refs/tags/21.10b0.zip
+pytorch @ https://download.pytorch.org/whl/cu102/torch-1.10.0%2Bcu102-cp39-cp39-linux_x86_64.whl
+An expected hash value may be specified by appending a #<HASH_ALGORITHM>=<EXPECTED_HASH> component:
requests @ https://github.com/psf/requests/archive/refs/tags/v2.26.0.zip#sha256=eb729a757f01c10546ebd179ae2aec852dd0d7f8ada2328ccf4558909d859985
+If the hash differs from the expected hash, the installation will fail.
It is recommended that only hashes which are unconditionally provided by the latest version of the standard library's hashlib module be used for hashes. As of Python 3.10, that list consists of:
md5sha1sha224sha256sha384sha512blake2bblake2s
Complex syntax¶
The following is an example that uses features and environment markers:
pkg[feature1,feature2] @ <REFERENCE> ; python_version < "3.7"
+Note that the space before the semicolon is required.
Advanced environment configuration¶
Context formatting¶
All environments support the following extra context formatting fields:
| Field | Description |
|---|---|
env_name | The name of the environment |
env_type | The type of environment |
matrix | Its modifier selects the value of that matrix variable. If the environment is not part of a matrix or was not generated with the variable, you must specify a default value as an additional modifier e.g. {matrix:version:v1.0.0}. |
verbosity | The integer verbosity value of Hatch. A flag modifier is supported that will render the value as a CLI flag e.g. -2 becomes -qq, 1 becomes -v, and 0 becomes an empty string. An additional flag integer modifier may be used to adjust the verbosity level. For example, if you wanted to make a command quiet by default, you could use {verbosity:flag:-1} within the command. |
args | For executed commands only, any extra command line arguments with an optional default modifier if none were provided |
Matrix¶
Environments can define a series of matrices with the matrix option:
[tool.hatch.envs.test]
+dependencies = [
+ "pytest"
+]
+
+[[tool.hatch.envs.test.matrix]]
+python = ["3.10", "3.11"]
+version = ["42", "3.14"]
+
+[[tool.hatch.envs.test.matrix]]
+python = ["3.11", "3.12"]
+version = ["9000"]
+feature = ["foo", "bar"]
+[envs.test]
+dependencies = [
+ "pytest"
+]
+
+[[envs.test.matrix]]
+python = ["3.10", "3.11"]
+version = ["42", "3.14"]
+
+[[envs.test.matrix]]
+python = ["3.11", "3.12"]
+version = ["9000"]
+feature = ["foo", "bar"]
+Doing so will result in the product of each variable combination being its own environment.
Naming¶
The name of the generated environments will be the variable values of each combination separated by hyphens, altogether prefixed by <ENV_NAME>.. For example, the following configuration:
[[tool.hatch.envs.test.matrix]]
+version = ["42"]
+feature = ["foo", "bar"]
+[[envs.test.matrix]]
+version = ["42"]
+feature = ["foo", "bar"]
+would indicate the following unique environments:
test.42-foo
+test.42-bar
+The exceptions to this format are described below.
Python variables¶
If the variables py or python are specified, then they will rank first in the product result and will be prefixed by py if the value is not. For example, the following configuration:
[[tool.hatch.envs.test.matrix]]
+version = ["42"]
+python = ["3.9", "pypy3"]
+[[envs.test.matrix]]
+version = ["42"]
+python = ["3.9", "pypy3"]
+would generate the following environments:
test.py3.9-42
+test.pypy3-42
+Note
The value of this variable sets the Python version.
Name formatting¶
You can set the matrix-name-format option to modify how each variable part is formatted which recognizes the placeholders {variable} and {value}. For example, the following configuration:
[tool.hatch.envs.test]
+matrix-name-format = "{variable}_{value}"
+
+[[tool.hatch.envs.test.matrix]]
+version = ["42"]
+feature = ["foo", "bar"]
+[envs.test]
+matrix-name-format = "{variable}_{value}"
+
+[[envs.test.matrix]]
+version = ["42"]
+feature = ["foo", "bar"]
+would produce the following environments:
test.version_42-feature_foo
+test.version_42-feature_bar
+By default this option is set to {value}.
Default environment¶
If the default environment defines matrices, then the generated names will not be prefixed by the environment name. This can be useful for projects that only need a single series of matrices without any standalone environments.
Selection¶
Rather than selecting a single generated environment, you can select the root environment to target all of them. For example, if you have the following configuration:
[tool.hatch.envs.test]
+dependencies = [
+ "coverage[toml]",
+ "pytest",
+ "pytest-cov",
+]
+
+[tool.hatch.envs.test.scripts]
+cov = 'pytest --cov-report=term-missing --cov-config=pyproject.toml --cov=pkg --cov=tests'
+
+[[tool.hatch.envs.test.matrix]]
+python = ["3.11", "3.12"]
+version = ["42", "3.14"]
+[envs.test]
+dependencies = [
+ "coverage[toml]",
+ "pytest",
+ "pytest-cov",
+]
+
+[envs.test.scripts]
+cov = 'pytest --cov-report=term-missing --cov-config=pyproject.toml --cov=pkg --cov=tests'
+
+[[envs.test.matrix]]
+python = ["3.11", "3.12"]
+version = ["42", "3.14"]
+you could then run your tests consecutively in all 4 environments with:
hatch run test:cov
+Option overrides¶
You can modify options based on the conditions of different sources like matrix variables with the overrides table, using dotted key syntax for each declaration:
[tool.hatch.envs.<ENV_NAME>.overrides]
+<SOURCE>.<CONDITION>.<OPTION> = <VALUE>
+[envs.<ENV_NAME>.overrides]
+<SOURCE>.<CONDITION>.<OPTION> = <VALUE>
+The type of the selected option determines the types of values.
Platform overrides¶
Options can be modified based on the current platform using the platform source.
[tool.hatch.envs.test.overrides]
+platform.windows.scripts = [
+ 'run=pytest -m "not io_uring"',
+]
+[envs.test.overrides]
+platform.windows.scripts = [
+ 'run=pytest -m "not io_uring"',
+]
+The following platforms are supported:
linuxwindowsmacos
Environment variable overrides¶
Environment variables can modify options using the env source.
[tool.hatch.envs.test.overrides]
+env.GITHUB_ACTIONS.dev-mode = { value = false, if = ["true"] }
+[envs.test.overrides]
+env.GITHUB_ACTIONS.dev-mode = { value = false, if = ["true"] }
+Matrix variable overrides¶
The matrix variables used to generate each environment can be used to modify options within using the matrix source.
[tool.hatch.envs.test.overrides]
+matrix.version.env-vars = "PRODUCT_VERSION"
+matrix.auth.features = [
+ { value = "oauth", if = ["oauth2"] },
+ { value = "kerberos", if = ["kerberos"] },
+]
+
+[[tool.hatch.envs.test.matrix]]
+python = ["3.11", "3.12"]
+version = ["legacy", "latest"]
+auth = ["oauth2", "kerberos", "noauth"]
+[envs.test.overrides]
+matrix.version.env-vars = "PRODUCT_VERSION"
+matrix.auth.features = [
+ { value = "oauth", if = ["oauth2"] },
+ { value = "kerberos", if = ["kerberos"] },
+]
+
+[[envs.test.matrix]]
+python = ["3.11", "3.12"]
+version = ["legacy", "latest"]
+auth = ["oauth2", "kerberos", "noauth"]
+Name overrides¶
When a matrix is defined, the name source can be used for regular expression matching on the generated name, minus the prefix for non-default environments.
[tool.hatch.envs.test.overrides]
+name."^0".env-vars = "TESTING_UNSTABLE=true"
+
+[[tool.hatch.envs.test.matrix]]
+version = ["0.1.0", "0.2.0", "1.0.0"]
+[envs.test.overrides]
+name."^0".env-vars = "TESTING_UNSTABLE=true"
+
+[[envs.test.matrix]]
+version = ["0.1.0", "0.2.0", "1.0.0"]
+Types¶
-
Literal types like strings for the Python version or booleans for skipping installation can be set using the value itself, an inline table, or an array. For example:
[tool.hatch.envs.test.overrides] +matrix.foo.python = "3.10" +matrix.bar.skip-install = { value = true, if = ["..."] } +env.CI.dev-mode = [ + { value = false, if = ["..."] }, + true, +] +[envs.test.overrides] +matrix.foo.python = "3.10" +matrix.bar.skip-install = { value = true, if = ["..."] } +env.CI.dev-mode = [ + { value = false, if = ["..."] }, + true, +] +For arrays, the first allowed value will be used.
-
Array types like dependencies or commands can be appended to using an array of strings or inline tables. For example:
[tool.hatch.envs.test.overrides] +matrix.foo.dependencies = [ + "httpx", + { value = "cryptography" }, +] +[envs.test.overrides] +matrix.foo.dependencies = [ + "httpx", + { value = "cryptography" }, +] + -
Mapping types like environment variables or scripts can have keys set using a string, or an array of strings or inline tables. For example:
[tool.hatch.envs.test.overrides] +matrix.foo.env-vars = "KEY=VALUE" +matrix.bar.env-vars = [ + "KEY1=VALUE1", + { key = "KEY2", value = "VALUE2" }, +] +[envs.test.overrides] +matrix.foo.env-vars = "KEY=VALUE" +matrix.bar.env-vars = [ + "KEY1=VALUE1", + { key = "KEY2", value = "VALUE2" }, +] +If the value is missing (no
=for strings, novaluekey for inline tables), then the value will be set to the value of the source condition.
Overwriting¶
Rather than supplementing the values within mapping types or array types, you can overwrite the option as a whole by prefixing the name with set-:
[tool.hatch.envs.test.overrides]
+matrix.foo.set-platforms = ["macos", "linux"]
+[envs.test.overrides]
+matrix.foo.set-platforms = ["macos", "linux"]
+When overwriting entire options or keys within mappings, override sources are applied in the following order:
Conditions¶
You may specify certain extra keys for any inline table that will determine whether or not to apply that entry. These modifiers may be combined with others and any negative evaluation will immediately cause the entry to be skipped.
Allowed values¶
The if key represents the allowed values for that condition. If the value of the condition is not listed, then that entry will not be applied:
[tool.hatch.envs.test.overrides]
+matrix.version.python = { value = "pypy", if = ["3.14"] }
+matrix.version.env-vars = [
+ { key = "KEY1", value = "VALUE1", if = ["42"] },
+ { key = "KEY2", value = "VALUE2", if = ["3.14"] },
+]
+
+[[tool.hatch.envs.test.matrix]]
+version = ["42", "3.14"]
+[envs.test.overrides]
+matrix.version.python = { value = "pypy", if = ["3.14"] }
+matrix.version.env-vars = [
+ { key = "KEY1", value = "VALUE1", if = ["42"] },
+ { key = "KEY2", value = "VALUE2", if = ["3.14"] },
+]
+
+[[envs.test.matrix]]
+version = ["42", "3.14"]
+Specific platforms¶
The platform key represents the desired platforms. If the current platform is not listed, then that entry will not be applied:
[tool.hatch.envs.test.overrides]
+env.EXPERIMENTAL.python = { value = "pypy", if = ["1"], platform = ["macos"] }
+matrix.version.env-vars = [
+ { key = "KEY1", value = "VALUE1", if = ["42"], platform = ["linux"] },
+ { key = "KEY2", value = "VALUE2", if = ["3.14"] },
+]
+
+[[tool.hatch.envs.test.matrix]]
+version = ["42", "3.14"]
+[envs.test.overrides]
+env.EXPERIMENTAL.python = { value = "pypy", if = ["1"], platform = ["macos"] }
+matrix.version.env-vars = [
+ { key = "KEY1", value = "VALUE1", if = ["42"], platform = ["linux"] },
+ { key = "KEY2", value = "VALUE2", if = ["3.14"] },
+]
+
+[[envs.test.matrix]]
+version = ["42", "3.14"]
+Required environment variables¶
The env key represents the required environment variables. If any of the listed environment variables are not set or the defined value does not match, then that entry will not be applied:
[tool.hatch.envs.test.overrides]
+platform.windows.python = { value = "pypy", env = ["EXPERIMENTAL"] }
+matrix.version.env-vars = [
+ { key = "KEY1", value = "VALUE1", if = ["42"], env = ["FOO", "BAR=BAZ"] },
+ { key = "KEY2", value = "VALUE2", if = ["3.14"] },
+]
+
+[[tool.hatch.envs.test.matrix]]
+version = ["42", "3.14"]
+[envs.test.overrides]
+platform.windows.python = { value = "pypy", env = ["EXPERIMENTAL"] }
+matrix.version.env-vars = [
+ { key = "KEY1", value = "VALUE1", if = ["42"], env = ["FOO", "BAR=BAZ"] },
+ { key = "KEY2", value = "VALUE2", if = ["3.14"] },
+]
+
+[[envs.test.matrix]]
+version = ["42", "3.14"]
+Environment configuration¶
All environments are defined as sections within the tool.hatch.envs table.
[tool.hatch.envs.<ENV_NAME>]
+[envs.<ENV_NAME>]
+The storage location for environments is completely configurable.
Unless an environment is explicitly selected on the command line, the default environment will be used. The type of this environment defaults to virtual.
Info
Environments prefixed by hatch- are used for special purposes e.g. testing.
Inheritance¶
All environments inherit from the environment defined by its template option, which defaults to default.
So for the following configuration:
[tool.hatch.envs.foo]
+type = "baz"
+skip-install = true
+
+[tool.hatch.envs.bar]
+template = "foo"
+skip-install = false
+[envs.foo]
+type = "baz"
+skip-install = true
+
+[envs.bar]
+template = "foo"
+skip-install = false
+the environment bar will be of type baz with skip-install set to false.
Note
Environments do not inherit matrices.
Self-referential environments¶
You can disable inheritance by setting template to the environment's own name:
[tool.hatch.envs.foo]
+template = "foo"
+[envs.foo]
+template = "foo"
+Detached environments¶
A common use case is standalone environments that do not require inheritance nor the installation of the project, such as for linting or sometimes building documentation. Enabling the detached option will make the environment self-referential and will skip project installation:
[tool.hatch.envs.lint]
+detached = true
+[envs.lint]
+detached = true
+Dependencies¶
You can install dependencies in addition to the ones defined by your project's metadata. Entries support context formatting.
[tool.hatch.envs.test]
+dependencies = [
+ "coverage[toml]",
+ "pytest",
+ "pytest-cov",
+ "pytest-mock",
+]
+[envs.test]
+dependencies = [
+ "coverage[toml]",
+ "pytest",
+ "pytest-cov",
+ "pytest-mock",
+]
+If you define environments with dependencies that only slightly differ from their inherited environments, you can use the extra-dependencies option to avoid redeclaring the dependencies option:
[tool.hatch.envs.default]
+dependencies = [
+ "foo",
+ "bar",
+]
+
+[tool.hatch.envs.experimental]
+extra-dependencies = [
+ "baz",
+]
+[envs.default]
+dependencies = [
+ "foo",
+ "bar",
+]
+
+[envs.experimental]
+extra-dependencies = [
+ "baz",
+]
+Tip
Hatch uses pip to install dependencies so any configuration it supports Hatch does as well. For example, if you wanted to only use a private repository you could set the PIP_INDEX_URL environment variable.
Installation¶
Features (extras)¶
If your project defines optional dependencies, you can select which groups to install using the features option:
[tool.hatch.envs.nightly]
+features = [
+ "server",
+ "grpc",
+]
+[envs.nightly]
+features = [
+ "server",
+ "grpc",
+]
+Note
Features/optional dependencies are also known as extras in other tools.
Dev mode¶
By default, environments will always reflect the current state of your project on disk. Set dev-mode to false to disable this behavior:
[tool.hatch.envs.static]
+dev-mode = false
+[envs.static]
+dev-mode = false
+Skip install¶
By default, environments will install your project during creation. To ignore this step, set skip-install to true:
[tool.hatch.envs.lint]
+skip-install = true
+[envs.lint]
+skip-install = true
+Environment variables¶
Defined¶
You can define environment variables with the env-vars option:
[tool.hatch.envs.docs]
+dependencies = [
+ "mkdocs"
+]
+[tool.hatch.envs.docs.env-vars]
+SOURCE_DATE_EPOCH = "1580601600"
+[envs.docs]
+dependencies = [
+ "mkdocs"
+]
+[envs.docs.env-vars]
+SOURCE_DATE_EPOCH = "1580601600"
+Values support context formatting.
Filters¶
By default, environments will have access to all environment variables. You can filter with wildcard patterns using the env-include/env-exclude options:
[tool.hatch.envs.<ENV_NAME>]
+env-include = [
+ "FOO*",
+]
+env-exclude = [
+ "BAR",
+]
+[envs.<ENV_NAME>]
+env-include = [
+ "FOO*",
+]
+env-exclude = [
+ "BAR",
+]
+Exclusion patterns take precedence but will never affect defined environment variables.
Scripts¶
You can define named scripts that may be executed or referenced at the beginning of other scripts. Context formatting is supported.
For example, in the following configuration:
[tool.hatch.envs.test]
+dependencies = [
+ "coverage[toml]",
+ "pytest",
+ "pytest-cov",
+ "pytest-mock",
+]
+[tool.hatch.envs.test.scripts]
+run-coverage = "pytest --cov-config=pyproject.toml --cov=pkg --cov=tests"
+run = "run-coverage --no-cov"
+[envs.test]
+dependencies = [
+ "coverage[toml]",
+ "pytest",
+ "pytest-cov",
+ "pytest-mock",
+]
+[envs.test.scripts]
+run-coverage = "pytest --cov-config=pyproject.toml --cov=pkg --cov=tests"
+run = "run-coverage --no-cov"
+the run script would be expanded to:
pytest --cov-config=pyproject.toml --cov=pkg --cov=tests --no-cov
+Scripts can also be defined as an array of strings.
[tool.hatch.envs.style]
+detached = true
+dependencies = [
+ "flake8",
+ "black",
+ "isort",
+]
+[tool.hatch.envs.style.scripts]
+check = [
+ "flake8 .",
+ "black --check --diff .",
+ "isort --check-only --diff .",
+]
+fmt = [
+ "isort .",
+ "black .",
+ "check",
+]
+[envs.style]
+detached = true
+dependencies = [
+ "flake8",
+ "black",
+ "isort",
+]
+[envs.style.scripts]
+check = [
+ "flake8 .",
+ "black --check --diff .",
+ "isort --check-only --diff .",
+]
+fmt = [
+ "isort .",
+ "black .",
+ "check",
+]
+Similar to make, you can ignore the exit code of commands that start with - (a hyphen). For example, the script error defined by the following configuration would halt after the second command with 3 as the exit code:
[tool.hatch.envs.test.scripts]
+error = [
+ "- exit 1",
+ "exit 3",
+ "exit 0",
+]
+[envs.test.scripts]
+error = [
+ "- exit 1",
+ "exit 3",
+ "exit 0",
+]
+Extra scripts¶
Individual scripts inherit from parent environments just like options. To guarantee that individual scripts do not override those defined by parent environments, you can use the extra-scripts option instead which is only capable of adding scripts that have not been defined.
Commands¶
All commands are able to use any defined scripts. Also like scripts, context formatting is supported and the exit code of commands that start with a hyphen will be ignored.
Pre-install¶
You can run commands immediately before environments install your project.
[tool.hatch.envs.<ENV_NAME>]
+pre-install-commands = [
+ "...",
+]
+[envs.<ENV_NAME>]
+pre-install-commands = [
+ "...",
+]
+Post-install¶
You can run commands immediately after environments install your project.
[tool.hatch.envs.<ENV_NAME>]
+post-install-commands = [
+ "...",
+]
+[envs.<ENV_NAME>]
+post-install-commands = [
+ "...",
+]
+Python version¶
The python option specifies which version of Python to use, or an absolute path to a Python interpreter:
[tool.hatch.envs.<ENV_NAME>]
+python = "3.10"
+[envs.<ENV_NAME>]
+python = "3.10"
+All environment types should respect this option.
Supported platforms¶
The platforms option indicates the operating systems with which the environment is compatible:
[tool.hatch.envs.<ENV_NAME>]
+platforms = ["linux", "windows", "macos"]
+[envs.<ENV_NAME>]
+platforms = ["linux", "windows", "macos"]
+The following platforms are supported:
linuxwindowsmacos
If unspecified, the environment is assumed to be compatible with all platforms.
Description¶
The description option is purely informational and is displayed in the output of the env show command:
[tool.hatch.envs.<ENV_NAME>]
+description = """
+Lorem ipsum ...
+"""
+[envs.<ENV_NAME>]
+description = """
+Lorem ipsum ...
+"""
+Type¶
An environment's type determines which environment plugin will be used for management. The only built-in environment type is virtual, which uses virtual Python environments.
Hatch configuration¶
Configuration for Hatch itself is stored in a config.toml file located by default in one of the following platform-specific directories.
| Platform | Path |
|---|---|
| macOS | ~/Library/Application Support/hatch |
| Windows | %USERPROFILE%\AppData\Local\hatch |
| Unix | $XDG_CONFIG_HOME/hatch (the XDG_CONFIG_HOME environment variable default is ~/.config) |
You can select a custom path to the file using the --config root option or by setting the HATCH_CONFIG environment variable.
The file can be managed by the config command group.
Mode¶
The mode key controls how Hatch selects the project to work on.
Local¶
mode = "local"
+By default, Hatch will look for a pyproject.toml file in the current working directory and any parent directories. The directory storing the first found file will be considered the project root.
Project¶
mode = "project"
+project = "proj1"
+
+[projects]
+proj1 = "/path/to/project1"
+proj2 = {"location": "/path/to/project2"}
+
+[dirs]
+project = ["/path/to/monorepo1", "/path/to/monorepo2"]
+In this mode, Hatch will only work on the selected project. The project is located using multiple heuristics:
- If the project is defined in the
projectstable then it must be a string, or an inline table with alocationkey, that is the full path to the project. - If the project matches a subdirectory in any of the directories listed in
dirs.project, then that will be used as the project root.
An error will occur if the project cannot be found.
You can use the config set command to change the project you are working on:
$ hatch config set project proj2
+New setting:
+project = "proj2"
+The project can be selected on a per-command basis with the -p/--project (environment variable HATCH_PROJECT) root option.
Aware¶
mode = "aware"
+This is essentially the local mode with a fallback to the project mode.
Shell¶
You can control the shell used to enter environments with the shell key.
If defined as a string, it must be the name of one of the supported shells and be available along your PATH.
shell = "fish"
+If the executable name of your shell differs from the supported name, you can define the shell as a table with name and path keys.
[shell]
+name = "bash"
+path = "/bin/ash"
+You can change the default arguments used to spawn most shells with the args key. The default for such supported shells is usually ["-i"].
[shell]
+name = "bash"
+args = ["--login"]
+Supported¶
| Shell | Name | Arguments | macOS | Windows | Unix |
|---|---|---|---|---|---|
| Almquist shell | ash | ["-i"] |  | | |
| Bash | bash | ["-i"] | | | |
| Command Prompt | cmd | | |||
| C shell | csh | ["-i"] | | | |
| fish | fish | ["-i"] | | | |
| Nushell | nu | [] | | | |
| PowerShell | pwsh, powershell | | | | |
| tcsh | tcsh | ["-i"] | | | |
| xonsh | xonsh | ["-i"] | | | |
| Z shell | zsh | ["-i"] | | |
Default¶
Hatch will attempt to use the current shell based on parent processes. If the shell cannot be determined, then on Windows systems Hatch will use the SHELL environment variable, if present, followed by the COMSPEC environment variable, defaulting to cmd. On all other platforms only the SHELL environment variable will be used, defaulting to bash.
Directories¶
Data¶
[dirs]
+data = "..."
+This is the directory that is used to persist data. By default it is set to one of the following platform-specific directories.
| Platform | Path |
|---|---|
| macOS | ~/Library/Application Support/hatch |
| Windows | %USERPROFILE%\AppData\Local\hatch |
| Unix | $XDG_DATA_HOME/hatch (the XDG_DATA_HOME environment variable default is ~/.local/share) |
You can select a custom path to the directory using the --data-dir root option or by setting the HATCH_DATA_DIR environment variable.
Cache¶
[dirs]
+cache = "..."
+This is the directory that is used to cache data. By default it is set to one of the following platform-specific directories.
| Platform | Path |
|---|---|
| macOS | ~/Library/Caches/hatch |
| Windows | %USERPROFILE%\AppData\Local\hatch\Cache |
| Unix | $XDG_CACHE_HOME/hatch (the XDG_CACHE_HOME environment variable default is ~/.cache) |
You can select a custom path to the directory using the --cache-dir root option or by setting the HATCH_CACHE_DIR environment variable.
Environments¶
[dirs.env]
+<ENV_TYPE> = "..."
+This determines where to store environments, with every key being the type of environment and the value being the desired storage location.
For example, if you wanted to store virtual environments in a .virtualenvs directory within your home directory, you could specify the following:
[dirs.env]
+virtual = "~/.virtualenvs"
+Any environment variables are also expanded.
If the path is not absolute, then it will be relative to the project root. So if you wanted to use a directory named .hatch in each project directory, you could do:
[dirs.env]
+virtual = ".hatch"
+Any type of environment that is not explicitly defined will default to <DATA_DIR>/env/<ENV_TYPE>.
Python installations¶
[dirs]
+python = "..."
+This determines where to install specific versions of Python.
The following values have special meanings:
| Value | Path |
|---|---|
isolated (default) | <DATA_DIR>/pythons |
Terminal¶
You can configure how all output is displayed using the terminal.styles table. These settings are also applied to all plugins.
[terminal.styles]
+error = "..."
+...
+Cross-platform terminal capabilities are provided by Rich.
Output levels¶
The levels of output are as follows. Note that the verbosity indicates the minimum level at which the output is displayed.
| Level | Default | Verbosity | Description |
|---|---|---|---|
debug | bold | 1 - 3 | Messages that are not useful for most user experiences |
error | bold red | -2 | Messages indicating some unrecoverable error |
info | bold | 0 | Messages conveying basic information |
success | bold cyan | 0 | Messages indicating some positive outcome |
waiting | bold magenta | 0 | Messages shown before potentially time consuming operations |
warning | bold yellow | -1 | Messages conveying important information |
See the documentation and color reference for guidance on valid values.
Spinner¶
You can select the sequence used for waiting animations with the spinner option.
[terminal.styles]
+spinner = "..."
+Static analysis configuration¶
Static analysis performed by the fmt command is (by default) backed entirely by Ruff.
Hatch provides default settings that user configuration can extend.
Extending config¶
When defining your configuration, be sure to use options that are prefixed by extend- such as extend-select, for example:
[tool.ruff.format]
+preview = true
+quote-style = "single"
+
+[tool.ruff.lint]
+preview = true
+extend-select = ["C901"]
+
+[tool.ruff.lint.extend-per-file-ignores]
+"docs/.hooks/*" = ["INP001", "T201"]
+
+[tool.ruff.lint.isort]
+known-first-party = ["foo", "bar"]
+[format]
+preview = true
+quote-style = "single"
+
+[lint]
+preview = true
+extend-select = ["C901"]
+
+[lint.extend-per-file-ignores]
+"docs/.hooks/*" = ["INP001", "T201"]
+
+[lint.isort]
+known-first-party = ["foo", "bar"]
+Note
When not persisting config, there is no need to explicitly extend the defaults as Hatch automatically handles that.
Persistent config¶
If you want to store the default configuration in the project, set an explicit path like so:
[tool.hatch.envs.hatch-static-analysis]
+config-path = "ruff_defaults.toml"
+[envs.hatch-static-analysis]
+config-path = "ruff_defaults.toml"
+Then instruct Ruff to consider your configuration as an extension of the default file:
[tool.ruff]
+extend = "ruff_defaults.toml"
+extend = "ruff_defaults.toml"
+Anytime you wish to update the defaults (such as when upgrading Hatch), you must run the fmt command once with the --sync flag e.g.:
hatch fmt --check --sync
+Tip
This is the recommended approach since it allows other tools like IDEs to use the default configuration.
No config¶
If you don't want Hatch to use any of its default configuration and rely entirely on yours, set the path to anything and then simply don't extend in your Ruff config:
[tool.hatch.envs.hatch-static-analysis]
+config-path = "none"
+[envs.hatch-static-analysis]
+config-path = "none"
+Customize behavior¶
You can fully alter the behavior of the environment used by the fmt command. See the how-to for a detailed example.
Dependencies¶
Pin the particular version of Ruff by explicitly defining the environment dependencies:
[tool.hatch.envs.hatch-static-analysis]
+dependencies = ["ruff==X.Y.Z"]
+[envs.hatch-static-analysis]
+dependencies = ["ruff==X.Y.Z"]
+Scripts¶
If you want to change the default commands that are executed, you can override the scripts. The following four scripts must be defined:
[tool.hatch.envs.hatch-static-analysis.scripts]
+format-check = "..."
+format-fix = "..."
+lint-check = "..."
+lint-fix = "..."
+[envs.hatch-static-analysis.scripts]
+format-check = "..."
+format-fix = "..."
+lint-check = "..."
+lint-fix = "..."
+The format-* scripts correspond to the --formatter/-f flag while the lint-* scripts correspond to the --linter/-l flag. The *-fix scripts run by default while the *-check scripts correspond to the --check flag.
Reminder
If you choose to use different tools for static analysis, be sure to update the required dependencies.
Installer¶
By default, UV is enabled. You may disable that behavior as follows:
[tool.hatch.envs.hatch-static-analysis]
+installer = "pip"
+[envs.hatch-static-analysis]
+installer = "pip"
+Default settings¶
Non-rule settings¶
- Line length set to 120
- Docstring formatting enabled with line length set to 80
- Only absolute imports are allowed, except for tests
- The normalized project name is a known first party import
Per-file ignored rules¶
Selected rules¶
The following rules are based on version 0.4.5 of Ruff. Rules with a P are only selected when preview mode is enabled.
There are 525 selected stable rules and 129 selected preview rules.
Selected rules
- A001, A002, A003
- ARG001, ARG002, ARG003, ARG004, ARG005
- ASYNC100, ASYNC101, ASYNC102
- B002, B003, B004, B005, B006, B007, B008, B009, B010, B011, B012, B013, B014, B015, B016, B017, B018, B019, B020, B021, B022, B023, B024, B025, B026, B028, B029, B030, B031, B032, B033, B034, B035, B904, B905, B909P
- BLE001
- C400, C401, C402, C403, C404, C405, C406, C408, C409, C410, C411, C413, C414, C415, C416, C417, C418, C419
- COM818
- DTZ001, DTZ002, DTZ003, DTZ004, DTZ005, DTZ006, DTZ007, DTZ011, DTZ012
- E101, E112P, E113P, E115P, E116P, E201P, E202P, E203P, E211P, E221P, E222P, E223P, E224P, E225P, E226P, E227P, E228P, E231P, E241P, E242P, E251P, E252P, E261P, E262P, E265P, E266P, E271P, E272P, E273P, E274P, E275P, E401, E402, E502P, E701, E702, E703, E711, E712, E713, E714, E721, E722, E731, E741, E742, E743, E902, E999
- EM101, EM102, EM103
- EXE001, EXE002, EXE003, EXE004, EXE005
- F401, F402, F403, F404, F405, F406, F407, F501, F502, F503, F504, F505, F506, F507, F508, F509, F521, F522, F523, F524, F525, F541, F601, F602, F621, F622, F631, F632, F633, F634, F701, F702, F704, F706, F707, F722, F811, F821, F822, F823, F841, F842, F901
- FA100, FA102
- FBT001, FBT002
- FLY002
- FURB105P, FURB110P, FURB113P, FURB116P, FURB118P, FURB129P, FURB131P, FURB132P, FURB136P, FURB142P, FURB145P, FURB148P, FURB152P, FURB157P, FURB161P, FURB163P, FURB164P, FURB166P, FURB167P, FURB168P, FURB169P, FURB171P, FURB177P, FURB180P, FURB181P, FURB187P, FURB192P
- G001, G002, G003, G004, G010, G101, G201, G202
- I001, I002
- ICN001, ICN002, ICN003
- INP001
- INT001, INT002, INT003
- ISC003
- LOG001, LOG002, LOG007, LOG009
- N801, N802, N803, N804, N805, N806, N807, N811, N812, N813, N814, N815, N816, N817, N818, N999
- PERF101, PERF102, PERF401, PERF402, PERF403P
- PGH005
- PIE790, PIE794, PIE796, PIE800, PIE804, PIE807, PIE808, PIE810
- PLC0105, PLC0131, PLC0132, PLC0205, PLC0208, PLC0414, PLC0415P, PLC1901P, PLC2401P, PLC2403P, PLC2701P, PLC2801P, PLC3002
- PLE0100, PLE0101, PLE0116, PLE0117, PLE0118, PLE0237, PLE0241, PLE0302, PLE0307, PLE0604, PLE0605, PLE0115P, PLE0303P, PLE0304P, PLE0305P, PLE0308P, PLE0309P, PLE0643P, PLE0704P, PLE1142, PLE1205, PLE1206, PLE1300, PLE1307, PLE1310, PLE1507, PLE1700, PLE1132P, PLE1141P, PLE1519P, PLE1520P, PLE2502, PLE2510, PLE2512, PLE2513, PLE2514, PLE2515, PLE4703P
- PLR0124, PLR0133, PLR0206, PLR0402, PLR0202P, PLR0203P, PLR1701, PLR1711, PLR1714, PLR1722, PLR1704P, PLR1730P, PLR1733P, PLR1736P, PLR2004, PLR2044P, PLR5501, PLR6104P, PLR6201P, PLR6301P
- PLW0120, PLW0127, PLW0129, PLW0131, PLW0406, PLW0602, PLW0603, PLW0711, PLW0108P, PLW0128P, PLW0133P, PLW0177P, PLW0211P, PLW0245P, PLW0604P, PLW0642P, PLW1508, PLW1509, PLW1510, PLW1501P, PLW1514P, PLW1641P, PLW2901, PLW2101P, PLW3301, PLW3201P
- PT001, PT002, PT003, PT006, PT007, PT008, PT009, PT010, PT011, PT012, PT013, PT014, PT015, PT016, PT017, PT018, PT019, PT020, PT021, PT022, PT023, PT024, PT025, PT026, PT027
- PYI001, PYI002, PYI003, PYI004, PYI005, PYI006, PYI007, PYI008, PYI009, PYI010, PYI011, PYI012, PYI013, PYI014, PYI015, PYI016, PYI017, PYI018, PYI019, PYI020, PYI021, PYI024, PYI025, PYI026, PYI029, PYI030, PYI032, PYI033, PYI034, PYI035, PYI036, PYI041, PYI042, PYI043, PYI044, PYI045, PYI046, PYI047, PYI048, PYI049, PYI050, PYI051, PYI052, PYI053, PYI054, PYI055, PYI056, PYI058, PYI059P, PYI062P
- RET503, RET504, RET505, RET506, RET507, RET508
- RSE102
- RUF001, RUF002, RUF003, RUF005, RUF006, RUF007, RUF008, RUF009, RUF010, RUF012, RUF013, RUF015, RUF016, RUF017, RUF018, RUF019, RUF020, RUF021P, RUF022P, RUF023P, RUF024P, RUF025P, RUF026P, RUF027P, RUF028P, RUF029P, RUF100, RUF101P
- S101, S102, S103, S104, S105, S106, S107, S108, S110, S112, S113, S201, S202, S301, S302, S303, S304, S305, S306, S307, S308, S310, S311, S312, S313, S314, S315, S316, S317, S318, S319, S320, S321, S323, S324, S401P, S402P, S403P, S405P, S406P, S407P, S408P, S409P, S411P, S412P, S413P, S415P, S501, S502, S503, S504, S505, S506, S507, S508, S509, S601, S602, S604, S605, S606, S607, S608, S609, S611, S612, S610P, S701, S702
- SIM101, SIM102, SIM103, SIM105, SIM107, SIM108, SIM109, SIM110, SIM112, SIM113, SIM114, SIM115, SIM116, SIM117, SIM118, SIM201, SIM202, SIM208, SIM210, SIM211, SIM212, SIM220, SIM221, SIM222, SIM223, SIM300, SIM910, SIM911
- SLF001
- SLOT000, SLOT001, SLOT002
- T100, T201, T203
- TCH001, TCH002, TCH003, TCH004, TCH005, TCH010
- TD004, TD005, TD006, TD007
- TID251, TID252, TID253
- TRIO100, TRIO105, TRIO109, TRIO110, TRIO115
- TRY002, TRY003, TRY004, TRY201, TRY300, TRY301, TRY302, TRY400, TRY401
- UP001, UP003, UP004, UP005, UP006, UP007, UP008, UP009, UP010, UP011, UP012, UP013, UP014, UP015, UP017, UP018, UP019, UP020, UP021, UP022, UP023, UP024, UP025, UP026, UP027, UP028, UP029, UP030, UP031, UP032, UP033, UP034, UP035, UP036, UP037, UP038, UP039, UP040, UP041, UP042P
- W291, W292, W293, W391P, W505, W605
- YTT101, YTT102, YTT103, YTT201, YTT202, YTT203, YTT204, YTT301, YTT302, YTT303
Unselected¶
There are 175 unselected rules.
Unselected rules
- AIR001
- ANN001, ANN002, ANN003, ANN101, ANN102, ANN201, ANN202, ANN204, ANN205, ANN206, ANN401
- B027
- C901
- COM812, COM819
- CPY001
- D100, D101, D102, D103, D104, D105, D106, D107, D200, D201, D202, D203, D204, D205, D206, D207, D208, D209, D210, D211, D212, D213, D214, D215, D300, D301, D400, D401, D402, D403, D404, D405, D406, D407, D408, D409, D410, D411, D412, D413, D414, D415, D416, D417, D418, D419
- DJ001, DJ003, DJ006, DJ007, DJ008, DJ012, DJ013
- E111, E114, E117, E301, E302, E303, E304, E305, E306, E501
- ERA001
- FBT003
- FIX001, FIX002, FIX003, FIX004
- FURB101, FURB103, FURB140
- ISC001, ISC002
- NPY001, NPY002, NPY003, NPY201
- PD002, PD003, PD004, PD007, PD008, PD009, PD010, PD011, PD012, PD013, PD015, PD101, PD901
- PERF203
- PGH001, PGH002, PGH003, PGH004
- PLR0904, PLR0911, PLR0912, PLR0913, PLR0914, PLR0915, PLR0916, PLR0917, PLR1702, PLR1706
- PT004, PT005
- PTH100, PTH101, PTH102, PTH103, PTH104, PTH105, PTH106, PTH107, PTH108, PTH109, PTH110, PTH111, PTH112, PTH113, PTH114, PTH115, PTH116, PTH117, PTH118, PTH119, PTH120, PTH121, PTH122, PTH123, PTH124, PTH201, PTH202, PTH203, PTH204, PTH205, PTH206, PTH207
- Q000, Q001, Q002, Q003, Q004
- RET501, RET502
- RUF011, RUF200
- S404, S410, S603
- SIM401
- TD001, TD002, TD003
- TRY200
- W191
Testing configuration¶
Check out the testing overview tutorial for a more comprehensive walk-through.
Settings¶
If an option has a corresponding test command flag, the flag will always take precedence.
Default arguments¶
You can define default arguments for the test command by setting the default-args option, which must be an array of strings. The following is the default configuration:
[tool.hatch.envs.hatch-test]
+default-args = ["tests"]
+[envs.hatch-test]
+default-args = ["tests"]
+Extra arguments¶
You can define extra internal arguments for test scripts by setting the extra-args option, which must be an array of strings. For example, if you wanted to increase the verbosity of pytest, you could set the following:
[tool.hatch.envs.hatch-test]
+extra-args = ["-vv"]
+[envs.hatch-test]
+extra-args = ["-vv"]
+Randomize test order¶
You can randomize the order of tests by enabling the randomize option which corresponds to the --randomize/-r flag:
[tool.hatch.envs.hatch-test]
+randomize = true
+[envs.hatch-test]
+randomize = true
+Parallelize test execution¶
You can parallelize test execution by enabling the parallel option which corresponds to the --parallel/-p flag:
[tool.hatch.envs.hatch-test]
+parallel = true
+[envs.hatch-test]
+parallel = true
+Retry failed tests¶
You can retry failed tests by setting the retries option which corresponds to the --retries flag:
[tool.hatch.envs.hatch-test]
+retries = 2
+[envs.hatch-test]
+retries = 2
+You can also set the number of seconds to wait between retries by setting the retry-delay option which corresponds to the --retry-delay flag:
[tool.hatch.envs.hatch-test]
+retry-delay = 1
+[envs.hatch-test]
+retry-delay = 1
+Customize environment¶
You can fully alter the behavior of the environment used by the test command.
Dependencies¶
You can define extra dependencies that your tests may require:
[tool.hatch.envs.hatch-test]
+extra-dependencies = [
+ "pyfakefs",
+ "pytest-asyncio",
+ "pytest-benchmark",
+ "pytest-memray",
+ "pytest-playwright",
+ "pytest-print",
+]
+[envs.hatch-test]
+extra-dependencies = [
+ "pyfakefs",
+ "pytest-asyncio",
+ "pytest-benchmark",
+ "pytest-memray",
+ "pytest-playwright",
+ "pytest-print",
+]
+The following is the default configuration:
[tool.hatch.envs.hatch-test]
+dependencies = [
+ "coverage-enable-subprocess==1.0",
+ "coverage[toml]~=7.4",
+ "pytest~=8.1",
+ "pytest-mock~=3.12",
+ "pytest-randomly~=3.15",
+ "pytest-rerunfailures~=14.0",
+ "pytest-xdist[psutil]~=3.5",
+]
+[envs.hatch-test]
+dependencies = [
+ "coverage-enable-subprocess==1.0",
+ "coverage[toml]~=7.4",
+ "pytest~=8.1",
+ "pytest-mock~=3.12",
+ "pytest-randomly~=3.15",
+ "pytest-rerunfailures~=14.0",
+ "pytest-xdist[psutil]~=3.5",
+]
+Matrix¶
You can override the default series of matrices:
[[tool.hatch.envs.hatch-test.matrix]]
+python = ["3.13", "3.12", "3.11", "3.10", "3.9", "3.8"]
+[[envs.hatch-test.matrix]]
+python = ["3.13", "3.12", "3.11", "3.10", "3.9", "3.8"]
+Scripts¶
If you want to change the default commands that are executed, you can override the scripts. The following default scripts must be redefined:
[tool.hatch.envs.hatch-test.scripts]
+run = "pytest{env:HATCH_TEST_ARGS:} {args}"
+run-cov = "coverage run -m pytest{env:HATCH_TEST_ARGS:} {args}"
+cov-combine = "coverage combine"
+cov-report = "coverage report"
+[envs.hatch-test.scripts]
+run = "pytest{env:HATCH_TEST_ARGS:} {args}"
+run-cov = "coverage run -m pytest{env:HATCH_TEST_ARGS:} {args}"
+cov-combine = "coverage combine"
+cov-report = "coverage report"
+The run script is the default behavior while the run-cov script is used instead when measuring code coverage. The cov-combine script runs after all tests complete when measuring code coverage, as well as the cov-report script when not using the --cover-quiet flag.
Note
The HATCH_TEST_ARGS environment variable is how the test command's flags are translated and internally populated without affecting the user's arguments. This is also the way that extra arguments are passed.
Installer¶
By default, UV is enabled. You may disable that behavior as follows:
[tool.hatch.envs.hatch-test]
+installer = "pip"
+[envs.hatch-test]
+installer = "pip"
+Configuring project metadata¶
Project metadata is stored in a pyproject.toml file located at the root of a project's tree and is based entirely on the standard.
Name (required)¶
The name of the project.
[project]
+name = "your-app"
+Version (required)¶
See the dedicated versioning section.
[project]
+...
+dynamic = ["version"]
+
+[tool.hatch.version]
+path = "..."
+[project]
+...
+version = "0.0.1"
+Description¶
A brief summary of the project.
[project]
+...
+description = '...'
+Readme¶
The full description of the project.
The file extension must be .md, .rst, or .txt.
[project]
+...
+readme = "README.md"
+The content-type field must be set to text/markdown, text/x-rst, or text/plain.
A charset field may also be set to instruct which encoding to use for reading the file, defaulting to utf-8.
[project]
+...
+readme = {"file" = "README.md", "content-type" = "text/markdown"}
+The content-type field must be set to text/markdown or text/x-rst.
[project]
+...
+readme = {"text" = "...", "content-type" = "text/markdown"}
+Note
If this is defined as a file, then it will always be included in source distributions for consistent builds.
Python support¶
The Python version requirements of the project.
[project]
+...
+requires-python = ">=3.8"
+License¶
For more information, see PEP 639.
[project]
+...
+license = "Apache-2.0 OR MIT"
+[project]
+...
+license-files = { paths = ["LICENSE.txt"] }
+[project]
+...
+license-files = { globs = ["LICENSES/*"] }
+Ownership¶
The people or organizations considered to be the authors or maintainers of the project. The exact meaning is open to interpretation; it may list the original or primary authors, current maintainers, or owners of the package. If the values are the same, prefer only the use of the authors field.
[project]
+...
+authors = [
+ { name = "...", email = "..." },
+]
+maintainers = [
+ { name = "...", email = "..." },
+]
+Keywords¶
The keywords used to assist in the discovery of the project.
[project]
+...
+keywords = [
+ "...",
+]
+Classifiers¶
The trove classifiers that apply to the project.
[project]
+...
+classifiers = [
+ "...",
+]
+URLs¶
A table of URLs where the key is the URL label and the value is the URL itself.
[project.urls]
+Documentation = "..."
+"Source code" = "..."
+Dependencies¶
See the dependency specification page for more information.
Entries support context formatting and disallow direct references by default.
Required¶
[project]
+...
+dependencies = [
+ "...",
+]
+Optional¶
[project.optional-dependencies]
+option1 = [
+ "...",
+]
+option2 = [
+ "...",
+]
+Entry points¶
Entry points are a mechanism for the project to advertise components it provides to be discovered and used by other code.
CLI¶
After installing projects that define CLI scripts, each key will be available along your PATH as a command that will call its associated object.
[project.scripts]
+cli-name = "pkg.subpkg:func"
+Using the above example, running cli-name would essentially execute the following Python script:
import sys
+
+from pkg.subpkg import func
+
+sys.exit(func())
+GUI¶
GUI scripts are exactly the same as CLI scripts except on Windows, where they are handled specially so that they can be started without a console.
[project.gui-scripts]
+gui-name = "pkg.subpkg:func"
+Plugins¶
[project.entry-points.plugin-namespace]
+plugin-name1 = "pkg.subpkg1"
+plugin-name2 = "pkg.subpkg2:func"
+Dynamic¶
If any metadata fields are set dynamically, like the version may be, then they must be listed here.
[project]
+...
+dynamic = [
+ "...",
+]
+Metadata options¶
Allowing direct references¶
By default, dependencies are not allowed to define direct references. To disable this check, set allow-direct-references to true:
[tool.hatch.metadata]
+allow-direct-references = true
+[metadata]
+allow-direct-references = true
+Allowing ambiguous features¶
By default, names of optional dependencies are normalized to prevent ambiguity. To disable this normalization, set allow-ambiguous-features to true:
[tool.hatch.metadata]
+allow-ambiguous-features = true
+[metadata]
+allow-ambiguous-features = true
+Deprecated
This option temporarily exists to provide better interoperability with tools that do not yet support PEP 685 and will be removed in the first minor release after Jan 1, 2024.
Project templates¶
You can control how new projects are created by the new command using Hatch's config file.
Author¶
[template]
+name = "..."
+email = "..."
+Licenses¶
[template.licenses]
+headers = true
+default = [
+ "MIT",
+]
+The list of licenses should be composed of SPDX identifiers. If multiple licenses are specified, then they will be placed in a LICENSES directory.
Options¶
Tests¶
This adds a tests directory with environments for testing and linting.
[template.plugins.default]
+tests = true
+CI¶
This adds a GitHub Actions workflow that runs tests on all platforms using modern versions of Python.
[template.plugins.default]
+ci = false
+src layout¶
See this blog post.
[template.plugins.default]
+src-layout = true
+Feature flags¶
Command line interface¶
The --cli flag adds a CLI backed by Click that can also be invoked with python -m <PKG_NAME>.
Environments¶
Environments are designed to allow for isolated workspaces for testing, building documentation, or anything else projects need.
Unless an environment is chosen explicitly, Hatch will use the default environment.
Tip
For a more comprehensive walk-through, see the Basic usage tutorial.
Creation¶
You can create environments by using the env create command. Let's enter the directory of the project we created in the setup phase:
$ hatch env create
+Creating environment: default
+Installing project in development mode
+Syncing dependencies
+Tip
You never need to manually create environments as spawning a shell or running commands within one will automatically trigger creation.
Entering environments¶
You can spawn a shell within an environment by using the shell command.
$ hatch shell
+(hatch-demo) $
+Now confirm the project has been installed:
(hatch-demo) $ pip show hatch-demo
+Name: hatch-demo
+Version: 0.0.1
+...
+Finally, see where your environment's Python is located:
(hatch-demo) $ python -c "import sys;print(sys.executable)"
+...
+You can type exit to leave the environment.
Command execution¶
The run command allows you to execute commands in an environment as if you had already entered it. For example, running the following command will output the same path as before:
hatch run python -c "import sys;print(sys.executable)"
+Tip
Be sure to check out how to define scripts for your project.
Dependencies¶
Hatch ensures that environments are always compatible with the currently defined project dependencies (if installed and in dev mode) and environment dependencies.
To add cowsay as a dependency, open pyproject.toml and add it to the dependencies array:
[project]
+...
+dependencies = [
+ "cowsay"
+]
+This dependency will be installed the next time you spawn a shell or run a command. For example:
$ hatch run cowsay -t "Hello, world!"
+Syncing dependencies
+ _____________
+| Hello, world! |
+ =============
+ \
+ \
+ ^__^
+ (oo)\_______
+ (__)\ )\/\
+ ||----w |
+ || ||
+Note
The Syncing dependencies status will display temporarily when Hatch updates environments in response to any dependency changes that you make.
Selection¶
You can select which environment to enter or run commands in by using the -e/--env root option or by setting the HATCH_ENV environment variable.
The run command allows for more explicit selection by prepending <ENV_NAME>: to commands. For example, if you had the following configuration:
[tool.hatch.envs.docs]
+dependencies = [
+ "mkdocs"
+]
+[tool.hatch.envs.docs.scripts]
+build = "mkdocs build --clean --strict"
+serve = "mkdocs serve --dev-addr localhost:8000"
+[envs.docs]
+dependencies = [
+ "mkdocs"
+]
+[envs.docs.scripts]
+build = "mkdocs build --clean --strict"
+serve = "mkdocs serve --dev-addr localhost:8000"
+you could then serve your documentation by running:
hatch run docs:serve
+Tip
If you've already entered an environment, commands will target it by default.
Matrix¶
Every environment can define its own set of matrices:
[tool.hatch.envs.test]
+dependencies = [
+ "pytest"
+]
+
+[[tool.hatch.envs.test.matrix]]
+python = ["3.10", "3.11"]
+version = ["42", "3.14"]
+
+[[tool.hatch.envs.test.matrix]]
+python = ["3.11", "3.12"]
+version = ["9000"]
+feature = ["foo", "bar"]
+[envs.test]
+dependencies = [
+ "pytest"
+]
+
+[[envs.test.matrix]]
+python = ["3.10", "3.11"]
+version = ["42", "3.14"]
+
+[[envs.test.matrix]]
+python = ["3.11", "3.12"]
+version = ["9000"]
+feature = ["foo", "bar"]
+Using the env show command would then display:
$ hatch env show --ascii
+ Standalone
++---------+---------+
+| Name | Type |
++=========+=========+
+| default | virtual |
++---------+---------+
+ Matrices
++------+---------+----------------------+--------------+
+| Name | Type | Envs | Dependencies |
++======+=========+======================+==============+
+| test | virtual | test.py3.10-42 | pytest |
+| | | test.py3.10-3.14 | |
+| | | test.py3.11-42 | |
+| | | test.py3.11-3.14 | |
+| | | test.py3.11-9000-foo | |
+| | | test.py3.11-9000-bar | |
+| | | test.py3.12-9000-foo | |
+| | | test.py3.12-9000-bar | |
++------+---------+----------------------+--------------+
+Removal¶
You can remove a single environment or environment matrix by using the env remove command or all of a project's environments by using the env prune command.
Hatch history¶
All notable changes to Hatch will be documented in this file.
The format is based on Keep a Changelog, and this project adheres to Semantic Versioning.
Unreleased¶
1.13.0 - 2024-10-13¶
Added:
- Support managing Python 3.13 distributions
1.12.0 - 2024-05-28¶
Changed:
- The
run/env runandtestcommands now treat inclusion variable options as an intersection rather than a union to allow for specific targeting of environments
Added:
- Add ability to control the source of Python distributions
- Upgrade Ruff to 0.4.5
- Upgrade PyApp to 0.22.0 for binary builds
Fixed:
- The
fmtcommand no longer hides the commands that are being executed - Add default timeout for network requests, useful when installing Python distributions
- Fix syntax highlighting contrast for the
config showcommand
1.11.1 - 2024-05-23¶
Added:
- Add official GitHub Action for installing Hatch
Fixed:
- Fix
terminal.styles.spinnerconfiguration - Fix entry points in the pre-built distributions that binaries use
1.11.0 - 2024-05-14¶
Added:
- Upgrade PyApp to 0.21.1 for binary builds
Fixed:
- On Linux, install the highest compatible Python distribution variant based on CPU architecture rather than assuming recent hardware
1.10.0 - 2024-05-02¶
Changed:
- The
run/env run,fmtandshellcommands now only change the current working directory to the project root if not already inside the project - The
shellcommand now accepts a single argument to specify the environment to enter which overrides the standard choice mechanisms. The arguments determining shell options have been converted to flags.
Added:
- Add
testcommand - The
runcommand can now execute scripts that define inline metadata for dependencies and Python version constraints - The
virtualenvironment type now supports the ability to use UV in place of pip & virtualenv - Add
self reportcommand for submitting pre-populated bug reports to GitHub - The reserved environment used for static analysis is now completely configurable
- Add the following methods to the
environmentinterface for complete control over output during life cycle management:app_status_creation,app_status_pre_installation,app_status_post_installation,app_status_project_installation,app_status_dependency_state_check,app_status_dependency_installation_check,app_status_dependency_synchronization - Add binaries for 32-bit versions of Windows
- Read configuration from any
~/.pypircfile for theindexpublisher - Use the Git user as the default username for new project URL metadata
- Add
HATCH_DEBUGenvironment variable that when enabled will show local variables in the case of unhandled tracebacks - The
env showcommand now outputs data about all internal environments when using the--jsonflag - Upgrade default CPython distributions to 20240415
- Upgrade default PyPy distributions to 7.3.15
- Upgrade Ruff to 0.4.2
- Upgrade PyApp to 0.19.0 for binary builds
- Bump the minimum supported version of Hatchling to 1.24.2
- Bump the minimum supported version of virtualenv to 20.26.1
Fixed:
- Maintain consistent data paths for case insensitive file systems
- When projects derive dependencies from metadata hooks, there is now by default a status indicator for when the hooks are executed for better responsiveness
- Properly support projects with a
pyproject.tomlfile but noprojecttable e.g. applications - Fix the
fmtcommand when automatically installing plugin dependencies - Fix dependency inheritance for the template of the
typesenvironment for new projects - Fix warnings related to tar file extraction on Python 3.12+ when unpacking Python distributions for installation
- De-select Ruff rule
E501for thefmtcommand by default since it conflicts with the formatter - Fix colored output from build targets on the first run (build environment creation status indicator issue)
- Set the
packagingdependency version as>=23.2to avoid its URL validation which can conflict with context formatting - Fix the exit code when there happens to be an unhandled exception
- No longer capture both stdout and stderr streams when parsing metadata payloads from build environments
- Fix the
README.mdfile template for new projects to avoid Markdown linting issues
1.9.7 - 2024-04-24¶
Fixed:
- Limit the maximum version of virtualenv due to a backward incompatible change
- Upgrade PyApp to 0.12.0 for binary builds
1.9.4 - 2024-03-12¶
Fixed:
- Limit the maximum version of Hatchling in anticipation of backward incompatible changes
1.9.3 - 2024-01-25¶
Fixed:
- Fix loading of local plugins to account for newly released versions of a dependency
1.9.2 - 2024-01-21¶
Fixed:
- Fix the default token variable name for publishing to PyPI
1.9.1 - 2023-12-25¶
Fixed:
- Ensure that the
dependency_hashmethod of theenvironmentinterface is called aftersync_dependenciesfor cases where the hash is only known at that point, such as for dependency lockers - Only acknowledge the
HATCH_PYTHON_VARIANT_*environment variables for Python resolution for supported platforms and architectures - Fix Python resolution when there are metadata hooks with unsatisfied dependencies
1.9.0 - 2023-12-19¶
Changed:
- Environments prefixed by
hatch-are now considered internal and used for special purposes such as configuration for static analysis
Added:
- Enable docstring formatting by default for static analysis
- Allow for overriding config of internal environments
- Concretely state the expected API contract for the environment interface methods
findandcheck_compatibility - Upgrade Ruff to 0.1.8
- Bump the minimum supported version of Hatchling to 1.21.0
Fixed:
- Ignore a project's Python requirement for environments where the project is not installed
- When not persisting config for static analysis, properly manage internal settings when Ruff's top level table already exists
- Ignore compatibility checks when environments have already been created, significantly improving performance of environment usage
- Properly allow overriding of the
pathoption for thevirtualenvironment type - Fix nushell activation on non-Windows systems
1.8.1 - 2023-12-14¶
Fixed:
- Fix regression in calling subprocesses with updated PATH
- Fix automatic installation of environment plugins when running as a standalone binary
- Change default location of Python installations
1.8.0 - 2023-12-11¶
Changed:
- Drop support for Python 3.7
- The
get_build_processmethod of theenvironmentinterface has been removed; plugins should use the newrun_buildermethod instead - Remove
pyperclipdependency and the--copyflag of theconfig findcommand - When running the
buildcommand all output from builders is now displayed as-is in real time without the stripping of ANSI codes - Version information (for Hatch itself) is now derived from Git
Added:
- Support Python 3.12
- Add installers and standalone binaries
- Add the ability to manage Python installations
- Add
fmtcommand - The
virtualenvironment type can now automatically download requested versions of Python that are not installed - Add
dependency_hashmethod to theenvironmentinterface - The state of installed dependencies for environments is saved as metadata so if dependency definitions have not changed then no checking is performed, which can be computationally expensive
- The
buildcommand now supports backends other than Hatchling - Allow the use of
featuresfor environments whenskip-installis enabled - The default is now
__token__when prompting for a username for thepublishcommand - Add a new
run_buildermethod to theenvironmentinterface - Bump the minimum supported version of Hatchling to 1.19.0
- Bump the minimum supported version of
clickto 8.0.6
Fixed:
- Fix nushell activation
- Better handling of flat storage directory hierarchies for the
virtualenvironment type - Display useful information when running the
versioncommand outside of a project rather than erroring - Fix the
project metadatacommand by only capturing stdout from the backend - Properly support Google Artifact Registry
- Fix parsing dependencies for environments when warnings are emitted
1.7.0 - 2023-04-03¶
Changed:
- The
src-layoutproject template option is now enabled by default - Non-critical output now goes to stderr
Added:
- Add
tool.hatch.env.requiresconfiguration to automatically install dependencies for environment and environment collector plugins - Add
customenvironment collector - Improve syncing of dependencies provided through Git direct references
- Add
isolated_data_directoryattribute to the environment interface - Increase the timeout for and add retries to the
indexpublisher - Expand home and environment variables in configured cache and data directories
- Improve readability of exceptions
- Update project templates
- Bump the minimum supported version of Hatchling to 1.14.0
Fixed:
- Fix displaying the version with the
versioncommand when the version is static and build dependencies are unmet - Fix build environments for the
virtualenvironment type when storing within a relative path - Work around System Integrity Protection on macOS when running commands
- Allow setuptools metadata migration for projects without
setup.pyifsetup.cfgis present - Handle additional edge cases for setuptools metadata migration
- Support boolean values for the
config setcommand
1.6.3 - 2022-10-24¶
Fixed:
- Fix
versioncommand when the version is dynamic and build dependencies are unmet
1.6.2 - 2022-10-20¶
Fixed:
- Fix getting dynamic metadata from hooks for environments when dependencies are not dynamic
1.6.1 - 2022-10-16¶
Fixed:
- Computing the path to the user's home directory now gracefully falls back to
~when it cannot be determined
1.6.0 - 2022-10-08¶
Changed:
- The
run_shell_commandenvironment interface method now accepts arbitrarysubprocess.Popenkeyword arguments. This is not strictly breaking, but will be utilized in upcoming features. - The internal directory structure for storing
virtualenvironments is now more nested. This is not breaking, but any local environments will be created anew.
Added:
- Add
projectcommand group to view details about the project like PEP 621 metadata - Better support for auto-detection of environments by tools like Visual Studio Code now that the storage directory of
virtualenvironments will be flat if Hatch's configuredvirtualenvironment directory resides somewhere within the project root or if it is set to a.virtualenvsdirectory within the user's home directory - Build environments for the
virtualenvironment type are now cached for improved performance - Add
build_environment_existsmethod to the environment interface for implementations that cache the build environment - Add
pathoption to thevirtualenvironment type - Add
--initialize-authflag to theindexpublisher to allow for the saving of authentication information before publishing - Support Bash on Windows for the
shellcommand - The
setuptoolsmigration script no longer modifies the formatting of existingpyproject.tomlconfiguration - Bump the minimum supported version of Hatchling to 1.11.0
Fixed:
- Environments now respect dynamically defined project dependencies
- The
dep hashand alldep showcommands now respect dynamically defined project dependencies - The
env show,dep hash, and alldep showcommands now honor context formatting - Fix matrix variable inclusion filtering of the
runandenv runcommands when there are multiple possible variables - Build environment compatibility is now checked before use
- Decreasing verbosity now has no affect on output that should always be displayed
- Handle more edge cases in the
setuptoolsmigration script - Environments now respect user defined environment variables for context formatting
- Update the scripts in the generated test environment template for new projects to reflect the documentation
- Allow
extra-dependenciesin environment overrides - Depend on
packagingexplicitly rather than relying on it being a transitive dependency of Hatchling
1.5.0 - 2022-08-28¶
Added:
- The
indexpublisher now recognizes repository-specific options - Add the
--ignore-compatflag to theenv runcommand - Setting the
HATCH_PYTHONenvironment variable toselfwill now force the use of the Python executable Hatch is running on forvirtualenvironment creation
Fixed:
- Fix the
--force-continueflag of theenv runcommand - Handle more edge cases in the
setuptoolsmigration script
1.4.2 - 2022-08-16¶
Fixed:
- Fix check for updating static versions with the
versioncommand when metadata hooks are in use
1.4.1 - 2022-08-13¶
Fixed:
- Fix non-detached inheritance disabling for environments
1.4.0 - 2022-08-06¶
Added:
- The default Python for
virtualenvironments now checks PATH before using the one Hatch is running on - Values for environment
env-varsnow support context formatting - Add
nameoverride for environments to allow for regular expression matching - The
indexpublisher now better supports non-PyPI indices - Add certificate options to the
indexpublisher - Display waiting text when checking dependencies and removing environments
- Display help text the first time the
shellcommand is executed - Update project templates with Python 3.11 and the latest versions of various GitHub Actions
- Add support for Almquist (
ash) shells - Add
hyperlinkas a dependency for better handling of package index URLs - Bump the minimum supported version of
virtualenvto 20.16.2 - Bump the minimum supported version of
tomlkitto 0.11.1
Fixed:
- Acknowledge
extra-dependenciesfor theenv showcommand - Fix locating executables within virtual environments on Debian
- Fix managing the terminal size inside the
shellcommand - Fix default code coverage file omission for the
src-layoutproject template option
1.3.1 - 2022-07-11¶
Fixed:
- Support
-h/--helpflag for theruncommand
1.3.0 - 2022-07-10¶
Changed:
- Rename the default publishing plugin from
pypito the more genericindex
Added:
- Support the absence of
pyproject.tomlfiles, as is the case for apps and non-Python projects - Hide scripts that start with an underscore for the
env showcommand by default - Ignoring the exit codes of commands by prefixing with hyphens now works with entire named scripts
- Add a way to require confirmation for publishing
- Add
--force-continueflag to theenv runcommand - Make tracebacks colorful and less verbose
- When shell configuration has not been defined, attempt to use the current shell based on parent processes before resorting to the defaults
- The shell name
pwshis now an alias forpowershell - Remove
atomicwritesdependency - Relax constraint on
userpathdependency - Bump the minimum supported version of Hatchling to 1.4.1
Fixed:
- Keep environments in sync with the dependencies of the selected features
- Use
utf-8for all files generated for new projects - Escape special characters Git may return in the user name when writing generated files for new projects
- Normalize the package name to lowercase in
setuptoolsmigration script - Fix parsing of source distributions during publishing
1.2.1 - 2022-05-30¶
Fixed:
- Fix handling of top level
data_filesinsetuptoolsmigration script
1.2.0 - 2022-05-22¶
Changed:
- The
enter_shellenvironment plugin method now accepts an additionalargsparameter
Added:
- Allow context string formatting for environment dependencies
- Add environment context string formatting fields
env_name,env_type,matrix,verbosity, andargs - Support overriding the default arguments used to spawn shells on non-Windows systems
- Bump the minimum supported version of Hatchling to 1.3.0
Fixed:
- Improve
setuptoolsmigration script
1.1.2 - 2022-05-20¶
Fixed:
- Bump the minimum supported version of Hatchling to 1.2.0
- Update project metadata to reflect support for Python 3.11
1.1.1 - 2022-05-12¶
Fixed:
- Fix
setuptoolsmigration script for non-Windows systems
1.1.0 - 2022-05-12¶
Changed:
- In order to simplify the implementation of command execution for environment plugins, the
run_shell_commandsmethod has been replaced by the singularrun_shell_command. A newcommand_contextmethod has been added to more easily satisfy complex use cases. - The
finalize_commandenvironment plugin method has been removed in favor of the newly introduced context formatting functionality.
Added:
- Add context formatting functionality i.e. the ability to insert values into configuration like environment variables and command line arguments
- Any verbosity for command execution will now always display headers, even for single environments
- Every executed command is now displayed when running multiple commands or when verbosity is enabled
- Similar to
make, ignore the exit code of executed commands that start with-(a hyphen) - Add ability for the
--initflag of thenewcommand to automatically migratesetuptoolsconfiguration - Update project metadata to reflect the adoption by PyPA and production stability
1.0.0 - 2022-04-28¶
This is the first stable release of Hatch v1, a complete rewrite. Enjoy!
Hatchling history¶
All notable changes to Hatchling will be documented in this file.
The format is based on Keep a Changelog, and this project adheres to Semantic Versioning.
Unreleased¶
Fixed:
- Ignore
manylinux/musllinuxtags for thewheeltarget artifact name when enabling theinfer_tagbuild data
1.24.2 - 2024-04-22¶
Fixed:
- Add
.venvto the list of directories that cannot be traversed - Output from the core Application utility now writes to stderr
1.24.1 - 2024-04-18¶
Fixed:
- Maintain file permissions for
shared-scriptsoption/shared_scriptsbuild data of thewheeltarget
1.24.0 - 2024-04-16¶
Added:
- Add
shared_dataandshared_scriptsbuild data for thewheeltarget
1.23.0 - 2024-04-14¶
Added:
- Add
shared-scriptsoption for thewheeltarget
Fixed:
- Support recursive optional dependencies
- Set the
packagingdependency version as>=23.2to avoid its URL validation which can conflict with context formatting
1.22.5 - 2024-04-04¶
Fixed:
- Fix reading metadata from source distributions when fields are dynamic but not part of core metadata like entry points
1.22.4 - 2024-03-23¶
Fixed:
- Only read source distribution metadata for fields that are explicitly defined as dynamic
1.22.3 - 2024-03-19¶
Fixed:
- Fix the
custombuild hook when using dynamic dependencies
1.22.2 - 2024-03-16¶
Fixed:
- Fix regression when loading metadata from source distributions
- Fix metadata hooks when building wheels from source distributions
1.22.1 - 2024-03-16¶
Fixed:
- Update the default version of core metadata to 2.3
1.22.0 - 2024-03-16¶
Deprecated:
- The
appbuild target has been renamed tobinaryto reduce ambiguity with the name of an upcoming feature. The former name will still be usable for several minor releases.
Added:
- Metadata for the
wheeltarget now defaults to thePKG-INFOmetadata within source distributions - Add
dependenciesmethod to the build hook interface so that hooks can themselves dynamically define dependencies - Update the default version of core metadata to 2.2
- Update SPDX license information to version 3.23
- Improve error message for when the default heuristics for wheel file inclusion fail
Fixed:
- Properly support core metadata version 2.2
- Remove
editablesas a direct dependency - Fix default wheel tag when the supported Python version declaration is strict
- Load VCS ignore patterns first so that whitelisted patterns can be excluded by project configuration
- Don't consider VCS ignore files that are outside of the VCS boundary
- The
sdistbuild target now gracefully ignores UNIX socket files - Begin ignoring certain files ubiquitously, like
.DS_Storeon macOS
1.21.1 - 2024-01-25¶
Fixed:
- Fix loading of local plugins to account for newly released versions of a dependency
1.21.0 - 2023-12-18¶
Added:
- Add
parentcontext modifier for path fields
1.20.0 - 2023-12-13¶
Added:
- Add
bypass-selectionoption to thewheelbuild target to allow for empty (metadata-only) wheels
Fixed:
- Fix regression in 1.19.1 that allowed
excludeto count toward inclusion selection, thus bypassing the default inclusion selection heuristics - Fix writing optional dependency core metadata in situations where there are multiple environment markers
1.19.1 - 2023-12-12¶
Fixed:
- Add better error message when the
wheelbuild target cannot determine what to ship - Consider forced inclusion patterns and build-time artifacts as file selection since some build hooks generate the entire wheel contents without user configuration
1.19.0 - 2023-12-11¶
Changed:
- An error will now be raised if a force-included path does not exist
- An error will now be raised for the
wheelbuild target if no file selection options are defined
Added:
- Officially support Python 3.12
- Allow using an empty string for the
sourcesoption to add a prefix to distribution paths
Fixed:
- Properly handle non-zero version epoch for the
standardversion scheme - Fix the
wheelbuild target for case insensitive file systems when the project metadata name does not match the directory name on disk - The
appbuild target no longer has suppressed output - Prevent duplicate paths when projects require the
sourcesoption while build hooks overwrite included paths - Properly escape spaces for URI context formatting
1.18.0 - 2023-06-12¶
Changed:
- Drop support for Python 3.7
Added:
- Update the list of directories that are always excluded for builds
1.17.1 - 2023-06-03¶
Fixed:
- Fix dev mode when the project has symlinks and file inclusion is defined with the
packagesoronly-includeoptions - Change the name of generated PTH files for dev mode so they come first lexicographically and therefore load first
1.17.0 - 2023-05-12¶
Added:
- The
appbuild target now embeds the project version in the name of binaries
1.16.1 - 2023-05-11¶
Fixed:
- Fix determining the built executable path for the
appbuild target option when using a local copy of PyApp when there is an explicit target triple set
1.16.0 - 2023-05-11¶
Added:
- Add
appbuild target option to build using a local copy of the PyApp repository
1.15.0 - 2023-05-09¶
Added:
- Add
appbuild target
1.14.1 - 2023-04-23¶
Fixed:
- Fix internal archive root naming for the
sdisttarget whenstrict-namingis disabled to match the file name in order to support the expectation of some frontends
1.14.0 - 2023-04-02¶
Added:
- Add
trove-classifiersas a dependency
Fixed:
- Properly normalize metadata descriptions that contain line breaks
1.13.0 - 2023-02-09¶
Added:
- Update the set of known trove classifiers to version 2023.2.8
1.12.2 - 2023-01-05¶
Fixed:
- Add
macos-max-compatoption to thewheeltarget that is enabled by default to support the latest version 22.0 of thepackaginglibrary
1.12.1 - 2022-12-31¶
Fixed:
- Fix minor regression in the PEP 517/660 function signatures that was discovered by Fedora
1.12.0 - 2022-12-30¶
Added:
- Improve readability of exceptions
- Add
extra_metadatabuild data to thewheeltarget - Retroactively support
License-Expressioncore metadata starting at version 2.1 - Add more type hints
- Update the set of known trove classifiers to version 2022.12.22
- Update SPDX license information to version 3.19
- Store Hatchling's metadata in
pyproject.toml
Fixed:
- Acknowledge the
ARCHFLAGSenvironment variable on macOS for thewheeltarget when build hooks set theinfer_tagbuild data totrue - Fix dependency checking when encountering broken distributions
- Fix the
support-legacyoption for thesdisttarget when using a src-layout project structure - Remove unnecessary encoding declaration in the default template for the
versionbuild hook
1.11.1 - 2022-10-19¶
Fixed:
- Fix default file selection behavior of the
wheeltarget when there is a single top-level module
1.11.0 - 2022-10-08¶
Added:
- Add
envversion source to retrieve the version from an environment variable - Add
validate-bumpoption to thestandardversion scheme
Fixed:
- Use proper CSV formatting for the
RECORDmetadata file of thewheeltarget to avoid warnings during installation bypipif, for example, file names contain commas - Fix installations with pip for build hooks that modify runtime dependencies
- Decreasing verbosity now has no affect on output that should always be displayed
1.10.0 - 2022-09-18¶
Added:
- Add the following to the list of directories that cannot be traversed:
__pypackages__,.hg,.hatch,.tox,.nox - Add deprecated option to allow ambiguous features
Fixed:
- Improve tracking of dynamic metadata
- Fix core metadata for entries in
project.optional-dependenciesthat use direct references
1.9.0 - 2022-09-09¶
Changed:
- File pattern matching now more closely resembles Git's behavior
Added:
- Implement a minimal version of
prepare_metadata_for_build_wheelandprepare_metadata_for_build_editablefor non-frontend tools that only need to inspect a project's metadata - Add
metadatacommand to view PEP 621 project metadata - Improve error messages for SPDX license errors
- Retroactively support
License-Filefor core metadata starting at version 2.1 - Bump the minimum supported version of
pathspecto 0.10.1
Fixed:
- Allow the valid non-SPDX
licensevaluesLicenseRef-Public-DomainandLicenseRef-Proprietary - Show the help text of the CLI when no subcommand is selected
1.8.1 - 2022-08-25¶
Fixed:
- Fix default file inclusion for
wheelbuild targets when both the project name and package directory name are not normalized
1.8.0 - 2022-08-16¶
Added:
- Add
get_known_classifiersmethod to metadata hooks
Fixed:
- Fix check for updating static versions with the
versioncommand when metadata hooks are in use
1.7.1 - 2022-08-13¶
Fixed:
- Fix the value of the
relative_pathattribute of included files, that some build plugins may use, when selecting explicit paths
1.7.0 - 2022-08-12¶
Added:
- Add
require-runtime-featuresoption for builders and build hooks - Check for unknown trove classifiers
- Update SPDX license information to version 3.18
Fixed:
- Add better error message for
wheeltarget dev mode installations that define path rewrites with thesourcesoption - Note the
allow-direct-referencesoption in the relevant error messages
1.6.0 - 2022-07-23¶
Changed:
- When no build targets are specified on the command line, now default to
sdistandwheeltargets rather than what happens to be defined in config - The
codeversion source now only supports files with known extensions - Global build hooks now run before target-specific build hooks to better match expected behavior
Added:
- The
codeversion source now supports loading extension modules - Add
search-pathsoption for thecodeversion source
Fixed:
- Fix removing
sourcesusing an empty string value in the mapping - The
strict-namingoption now also applies to the metadata directory ofwheeltargets
1.5.0 - 2022-07-11¶
Added:
- Support the final draft of PEP 639
- Add
strict-namingoption forsdistandwheeltargets
Fixed:
- Project names are now stored in
sdistandwheeltarget core metadata exactly as defined inpyproject.tomlwithout normalization to allow control of how PyPI displays them
1.4.1 - 2022-07-04¶
Fixed:
- Fix forced inclusion of important files like licenses for
sdisttargets when using the explicit selection options - Don't sort project URL metadata so that the rendered order on PyPI can be controlled
1.4.0 - 2022-07-03¶
Changed:
- The
packagesoption uses the newonly-includeoption to provide targeted inclusion, since that is desired most of the time. You can retain the old behavior by using theincludeandsourcesoptions together.
Added:
- Support PEP 561 type hinting
- Add
versionbuild hook - Add
only-includeoption - The
editableversion ofwheeltargets now respects theforce-includeoption by default - The
force-includeoption now supports path rewriting with thesourcesoption - The
wheeltargetshared-dataandextra-metadataoptions now respect file selection options - The
wheeltarget now auto-detects single module layouts - Improve performance by never entering directories that are guaranteed to be undesirable like
__pycache__rather than excluding individual files within - Update SPDX license information to version 3.17
Fixed:
- Don't write empty entry points file for
wheeltargets if there are no entry points defined - Allow metadata hooks to set the
versionin all cases - Prevent duplicate file entries from inclusion when using the
force-includeoption
1.3.1 - 2022-05-30¶
Fixed:
- Better populate global variables for the
codeversion source
1.3.0 - 2022-05-22¶
Removed:
- Remove unused global
argscontext string formatting field
Added:
- Improve error messages for the
envcontext string formatting field
Fixed:
- Fix
uricontext string formatting modifier on Windows
1.2.0 - 2022-05-20¶
Added:
- Allow context formatting for
project.dependenciesandproject.optional-dependencies
1.1.0 - 2022-05-19¶
Added:
- Add
uriandrealcontext string formatting modifiers for file system paths
1.0.0 - 2022-05-17¶
Changed:
- Drop support for Python 2
Added:
- Improve error messaging for invalid versions
- Update project metadata to reflect support for Python 3.11
0.25.1 - 2022-06-14¶
Fixed:
- Fix support for Windows on Python 2 by removing its support for symlinks
0.25.0 - 2022-05-15¶
Added:
- Add
skip-excluded-dirsbuild option - Allow build data to add additional project dependencies for
wheelandsdistbuild targets - Add
force_include_editablebuild data for thewheelbuild target - Add
build_hooksbuild data - Add support for Mercurial's
.hgignorefiles when using glob syntax - Update project metadata to reflect the adoption by PyPA
Fixed:
- Properly use underscores for the name of
force_includebuild data - No longer greedily skip excluded directories by default
0.24.0 - 2022-04-28¶
This is the initial public release of the Hatchling build system. Support for Python 2 will be dropped in version 1.
How to configure custom dynamic metadata¶
If you have project metadata that is not appropriate for static entry into pyproject.toml you will need to provide a custom metadata hook to apply such data during builds.
Alternatives
Dynamic metadata is a way to have a single source of truth that will be available at build time and at run time. Another way to achieve that is to enter the build data statically and then look up the same information dynamically in the program or package, using importlib.metadata.
If the version field is the only metadata of concern, Hatchling provides a few built-in ways such as the regex version source and also third-party plugins. The approach here will also work, but is more complex.
Update project metadata¶
Change the [project] section of pyproject.toml:
- Define the dynamic field as an array of all the fields you will set dynamically e.g.
dynamic = ["version", "license", "authors", "maintainers"] - If any of those fields have static definitions in
pyproject.toml, delete those definitions. It is verboten to define a field statically and dynamically.
Add a section to trigger loading of dynamic metadata plugins: [tool.hatch.metadata.hooks.custom]. Use exactly that name, regardless of the name of the class you will use or its PLUGIN_NAME. There doesn't need to be anything in the section.
If your plugin requires additional third-party packages to do its work, add them to the requires array in the [build-system] section of pyproject.toml.
Implement hook¶
The dynamic lookup must happen in a custom plugin that you write. The default expectation is that it is in a hatch_build.py file at the root of the project. Subclass MetadataHookInterface and implement update(); for example, here's plugin that reads metadata from a JSON file:
import json
+import os
+
+from hatchling.metadata.plugin.interface import MetadataHookInterface
+
+
+class JSONMetaDataHook(MetadataHookInterface):
+ def update(self, metadata):
+ src_file = os.path.join(self.root, "gnumeric", ".constants.json")
+ with open(src_file) as src:
+ constants = json.load(src)
+ metadata["version"] = constants["__version__"]
+ metadata["license"] = constants["__license__"]
+ metadata["authors"] = [
+ {"name": constants["__author__"], "email": constants["__author_email__"]},
+ ]
+- You must import the MetadataHookInterface to subclass it.
- Do your operations inside the
updatemethod. metadatarefers to project metadata.- When writing to metadata, use
listfor TOML arrays. Note that if a list is expected, it is required even if there is a single element. - Use
dictfor TOML tables e.g.authors.
If you want to store the hook in a different location, set the path option:
[tool.hatch.metadata.hooks.custom]
+path = "some/where.py"
+[metadata.hooks.custom]
+path = "some/where.py"
+How to configure dependency resolution¶
Most Hatch environment types, like the default virtual, simply use pip to install dependencies. Therefore, you can use the standard environment variables that influence pip's behavior.
Here's an example of setting up the default environment to look at 2 private indices (using context formatting for authentication) before finally falling back to PyPI:
[tool.hatch.envs.default.env-vars]
+PIP_INDEX_URL = "https://token:{env:GITLAB_API_TOKEN}@gitlab.com/api/v4/groups/<group1_path>/-/packages/pypi/simple/"
+PIP_EXTRA_INDEX_URL = "https://token:{env:GITLAB_API_TOKEN}@gitlab.com/api/v4/groups/<group2_path>/-/packages/pypi/simple/ https://pypi.org/simple/"
+[envs.default.env-vars]
+PIP_INDEX_URL = "https://token:{env:GITLAB_API_TOKEN}@gitlab.com/api/v4/groups/<group1_path>/-/packages/pypi/simple/"
+PIP_EXTRA_INDEX_URL = "https://token:{env:GITLAB_API_TOKEN}@gitlab.com/api/v4/groups/<group2_path>/-/packages/pypi/simple/ https://pypi.org/simple/"
+UV¶
If you're using UV, a different set of environment variables are available to configure its behavior. The previous example would look like this instead:
[tool.hatch.envs.default.env-vars]
+UV_EXTRA_INDEX_URL = "https://token:{env:GITLAB_API_TOKEN}@gitlab.com/api/v4/groups/<group1_path>/-/packages/pypi/simple/"
+UV_INDEX_URL = "https://token:{env:GITLAB_API_TOKEN}@gitlab.com/api/v4/groups/<group2_path>/-/packages/pypi/simple/ https://pypi.org/simple/"
+[envs.default.env-vars]
+UV_EXTRA_INDEX_URL = "https://token:{env:GITLAB_API_TOKEN}@gitlab.com/api/v4/groups/<group1_path>/-/packages/pypi/simple/"
+UV_INDEX_URL = "https://token:{env:GITLAB_API_TOKEN}@gitlab.com/api/v4/groups/<group2_path>/-/packages/pypi/simple/ https://pypi.org/simple/"
+Tip
If you need precise control over the prioritization of package indices, then using UV is recommended because pip has no index order guarantee.
How to select the installer¶
Enabling UV¶
The virtual environment type by default uses virtualenv for virtual environment creation and pip to install dependencies. You can speed up environment creation and dependency resolution by using UV instead of both of those tools.
caveat
UV is under active development and may not work for all dependencies.
To do so, set the installer option to uv. For example, if you wanted to enable this functionality for the default environment, you could set the following:
[tool.hatch.envs.default]
+installer = "uv"
+[envs.default]
+installer = "uv"
+Tip
All environments that enable UV will have the path to UV available as the HATCH_UV environment variable.
Configuring the version¶
The UV that is shared by all environments uses a specific version range that is known to work with Hatch. If you want to use a different version, you can override the dependencies for the internal hatch-uv environment:
[tool.hatch.envs.hatch-uv]
+dependencies = [
+ "uv>9000",
+]
+[envs.hatch-uv]
+dependencies = [
+ "uv>9000",
+]
+Externally managed¶
If you want to manage UV yourself, you can expose it to Hatch by setting the HATCH_ENV_TYPE_VIRTUAL_UV_PATH environment variable which should be the absolute path to a UV binary for Hatch to use instead. This implicitly enables UV.
Installer script alias¶
If you have scripts or commands that call pip, it may be useful to alias the uv pip command to pip so that you can use the same commands for both methods of configuration and retain your muscle memory. The following is an example of a matrix that conditionally enables UV and sets the alias:
[[tool.hatch.envs.example.matrix]]
+tool = ["uv", "pip"]
+
+[tool.hatch.envs.example.overrides]
+matrix.tool.installer = { value = "{matrix:tool}" }
+matrix.tool.scripts = [
+ { key = "pip", value = "{env:HATCH_UV} pip {args}", if = ["uv"] },
+]
+[[envs.example.matrix]]
+tool = ["uv", "pip"]
+
+[envs.example.overrides]
+matrix.tool.installer = { value = "{matrix:tool}" }
+matrix.tool.scripts = [
+ { key = "pip", value = "{env:HATCH_UV} pip {args}", if = ["uv"] },
+]
+Another common use case is to expose UV to all test environments. In this case, you often wouldn't want to modify the scripts mapping directly but rather add an extra script:
[tool.hatch.envs.hatch-test.extra-scripts]
+pip = "{env:HATCH_UV} pip {args}"
+[envs.hatch-test.extra-scripts]
+pip = "{env:HATCH_UV} pip {args}"
+How to use Hatch environments from Visual Studio Code¶
Visual Studio Code announced support for Hatch environment discovery in vscode-python's 2024.4 release.
For it to work, you should install Hatch globally. If you used the GUI installers on Windows or macOS, or your system package manager on e.g. Arch Linux or Fedora, this should be taken care of.
Setting up PATH
If you installed Hatch with pipx rather than system-wide, you might need to add $HOME/.local/bin to your PATH environment variable for your graphical session, not just your terminal. Check like this:
$ pgrep bin/code # or some other graphical application
+1234
+$ cat /proc/1234/environ | tr '\0' '\n' | grep -E '^PATH='
+PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
+If the directory is not in there, you need to add it in your session startup script, in a way that depends on your desktop environment:
Project setup¶
-
Make Hatch install the project and its dependencies to an environment using the
env createcommand. -
Select an interpreter using the Python: Select Interpreter command:
-
You should now be able to use the environment. For example, if you have the
python.terminal.activateEnvironmentsetting set totrueand you open a new terminal, the environment should be activated. Alternatively, you could press the "play" button to run a file in the environment:
How to report issues¶
All reports regarding unexpected behavior should be generated with the self report command:
$ hatch self report
+By default, this will open a new tab in your default browser with pre-populated information about your environment.
If Hatch is not installed alongside a web browser, you may also pass the --no-open/-n command which will output the URL with correct parameters for copying elsewhere:
$ hatch self report -n
+https://github.com/pypa/hatch/issues/new?body=%23%23+Current+behavior%0A%3C%21--+A+clear+and+concise+description+of+the+behavior.+--%3E%0A%0A%23%23+Expected+behavior%0A%3C%21--+A+clear+and+concise+description+of+what+you+expected+to+happen.+--%3E%0A%0A%23%23+Additional+context%0A%3C%21--+Add+any+other+context+about+the+problem+here.+If+applicable%2C+add+screenshots+to+help+explain.+--%3E%0A%0A%23%23+Debug%0A%0A%23%23%23+Installation%0A%0A-+Source%3A+pip%0A-+Version%3A+1.9.2.dev5%0A-+Platform%3A+Windows%0A-+Python+version%3A%0A++++%60%60%60%0A++++3.11.1+%28tags%2Fv3.11.1%3Aa7a450f%2C+Dec++6+2022%2C+19%3A58%3A39%29+%5BMSC+v.1934+64+bit+%28AMD64%29%5D%0A++++%60%60%60%0A%0A%23%23%23+Configuration%0A%0A%60%60%60toml%0Amode+%3D+%22local%22%0Ashell+%3D+%22nu%22%0A%60%60%60%0A
+Testing build plugins¶
For testing Hatchling plugins, you'll usually want to generate a project to execute builds as a real user would. For example, as a minimal pytest fixture:
from pathlib import Path
+
+import pytest
+
+
+@pytest.fixture
+def new_project(tmp_path):
+ project_dir = tmp_path / 'my-app'
+ project_dir.mkdir()
+
+ project_file = project_dir / 'pyproject.toml'
+ project_file.write_text(
+ f"""\
+[build-system]
+requires = ["hatchling", "hatch-plugin-name @ {Path.cwd().as_uri()}"]
+build-backend = "hatchling.build"
+
+[project]
+name = "my-app"
+version = "0.1.0"
+""",
+ encoding='utf-8',
+ )
+ ...
+The issue with this is that after the first test session, the project will be forever cached by pip based on the file path. Therefore, subsequent tests runs will never use updated code.
To invalidate the cache, copy your code to a new path for every test session:
import shutil
+from pathlib import Path
+from tempfile import TemporaryDirectory
+
+import pytest
+
+
+@pytest.fixture(scope='session')
+def plugin_dir():
+ with TemporaryDirectory() as d:
+ directory = Path(d, 'plugin')
+ shutil.copytree(
+ Path.cwd(), directory, ignore=shutil.ignore_patterns('.git')
+ )
+
+ yield directory.resolve()
+
+
+@pytest.fixture
+def new_project(tmp_path, plugin_dir):
+ project_dir = tmp_path / 'my-app'
+ project_dir.mkdir()
+
+ project_file = project_dir / 'pyproject.toml'
+ project_file.write_text(
+ f"""\
+[build-system]
+requires = ["hatchling", "hatch-plugin-name @ {plugin_dir.as_uri()}"]
+build-backend = "hatchling.build"
+
+[project]
+name = "my-app"
+version = "0.1.0"
+""",
+ encoding='utf-8',
+ )
+ ...
+Note
This example chooses to ignore copying .git for performance reasons. You may want to ignore more patterns, or copy only specific paths like this plugin does.
How to authenticate for index publishing¶
The username is derived from the following sources, in order of precedence:
- The
--user/-ucli option. - The
HATCH_INDEX_USERenvironment variable. - The
repostables. - The
~/.pypircfile. - The input to an interactive prompt.
As a fallback the value __token__ is applied.
The password is looked up in these:
- The
~/.pypircfile if the username was provided by it. - The
--auth/-acli option. - The
HATCH_INDEX_AUTHenvironment variable. - The
repostables. - A variety of OS-level credentials services backed by keyring.
- The input to an interactive prompt.
If interactively provided credentials were used, the username will be stored in Hatch's cache and the password stored in the available keyring backed credentials stores.
For automated releasing to PyPI, it is recommended to use "Trusted Publishing" with OIDC (e.g. PyPA's pypi-publish GitHub Action) or per-project API tokens.
How to configure repositories for index publishing¶
You can select the repository with which to upload using the -r/--repo option or by setting the HATCH_INDEX_REPO environment variable.
Rather than specifying the full URL of a repository, you can use a named repository from a publish.index.repos table defined in Hatch's config file:
[publish.index.repos.private]
+url = "..."
+...
+The following repository names are reserved by Hatch and cannot be overridden:
| Name | Repository |
|---|---|
main | https://upload.pypi.org/legacy/ |
test | https://test.pypi.org/legacy/ |
The main repository is used by default.
How to use custom Python distributions¶
The built-in Python management capabilities offer full support for using custom distributions.
Configuration¶
Configuring custom Python distributions is done entirely through three environment variables that must all be defined, for each desired distribution. In the following sections, the placeholder <NAME> is the uppercased version of the distribution name with periods replaced by underscores e.g. pypy3.10 would become PYPY3_10.
Source¶
The HATCH_PYTHON_CUSTOM_SOURCE_<NAME> variable is the URL to the distribution's archive. The value must end with the archive's real file extension, which is used to determine the extraction method.
The following extensions are supported:
| Extensions | Description |
|---|---|
| A tar file with bzip2 compression |
| A tar file with gzip compression |
| A tar file with Zstandard compression |
| A ZIP file with DEFLATE compression |
Python path¶
The HATCH_PYTHON_CUSTOM_PATH_<NAME> variable is the path to the Python interpreter within the archive. This path is relative to the root of the archive and must be a Unix-style path, even on Windows.
Version¶
The HATCH_PYTHON_CUSTOM_VERSION_<NAME> variable is the version of the distribution. This value is used to determine whether updates are required and is displayed in the output of the python show command.
How to run Python scripts¶
The run command supports executing Python scripts with inline metadata, such that a dedicated environment is automatically created with the required dependencies and with the correct version of Python.
A script metadata block is a comment block that starts with # /// script and ends with # ///. Every line between those two lines must be a comment line that starts with # and contains a TOML document when the comment characters are removed.
The top-level fields are:
dependencies: A list of strings that specifies the runtime dependencies of the script. Each entry must be a valid dependency specifier.requires-python: A string that specifies the Python version(s) with which the script is compatible. The value of this field must be a valid version specifier.
The following is an example of Python script with a valid metadata block:
# /// script
+# requires-python = ">=3.11"
+# dependencies = [
+# "httpx",
+# "rich",
+# ]
+# ///
+
+import httpx
+from rich.pretty import pprint
+
+resp = httpx.get("https://peps.python.org/api/peps.json")
+data = resp.json()
+pprint([(k, v["title"]) for k, v in data.items()][:10])
+Run it directly:
$ hatch run /path/to/script.py
+Creating environment: SyB4bPbL
+Checking dependencies
+Syncing dependencies
+[
+│ ('1', 'PEP Purpose and Guidelines'),
+│ ('2', 'Procedure for Adding New Modules'),
+│ ('3', 'Guidelines for Handling Bug Reports'),
+│ ('4', 'Deprecation of Standard Modules'),
+│ ('5', 'Guidelines for Language Evolution'),
+│ ('6', 'Bug Fix Releases'),
+│ ('7', 'Style Guide for C Code'),
+│ ('8', 'Style Guide for Python Code'),
+│ ('9', 'Sample Plaintext PEP Template'),
+│ ('10', 'Voting Guidelines')
+]
+notes
- The informational text in this example is only temporarily shown in your terminal on the first run.
- Although the environment name is based on the script's absolute path, the command line argument does not have to be.
Environment configuration¶
You may use the [tool.hatch] table directly to control the script's environment. For example, if you wanted to disable UV (which is enabled by default for scripts), you could add the following:
# /// script
+# ...
+# [tool.hatch]
+# installer = "pip"
+# ///
+Customize static analysis behavior¶
You can fully alter the static analysis performed by the fmt command by modifying the reserved environment named hatch-static-analysis. For example, you could define the following if you wanted to replace the default behavior with a mix of Black, isort and basic flake8:
[tool.hatch.envs.hatch-static-analysis]
+dependencies = ["black", "flake8", "isort"]
+
+[tool.hatch.envs.hatch-static-analysis.scripts]
+format-check = [
+ "black --check --diff {args:.}",
+ "isort --check-only --diff {args:.}",
+]
+format-fix = [
+ "isort {args:.}",
+ "black {args:.}",
+]
+lint-check = "flake8 {args:.}"
+lint-fix = "lint-check"
+[envs.hatch-static-analysis]
+dependencies = ["black", "flake8", "isort"]
+
+[envs.hatch-static-analysis.scripts]
+format-check = [
+ "black --check --diff {args:.}",
+ "isort --check-only --diff {args:.}",
+]
+format-fix = [
+ "isort {args:.}",
+ "black {args:.}",
+]
+lint-check = "flake8 {args:.}"
+lint-fix = "lint-check"
+The format-* scripts correspond to the --formatter/-f flag while the lint-* scripts correspond to the --linter/-l flag. The *-fix scripts run by default while the *-check scripts correspond to the --check flag. Based on this example, the following shows how the various scripts influence behavior:
| Command | Expanded scripts |
|---|---|
hatch fmt |
|
hatch fmt src tests |
|
hatch fmt -f |
|
hatch fmt -l |
|
hatch fmt --check |
|
hatch fmt --check -f |
|
hatch fmt --check -l |
|
Hatch¶
| CI/CD |    |
| Docs |   |
| Package |     |
| Meta |      |
Hatch is a modern, extensible Python project manager. See the Why Hatch? page for more information.
-
Build system
Reproducible builds by default with a rich ecosystem of plugins
-
Environments
Robust environment management with support for custom scripts and UV
-
Python management
Choose between easy manual installations or automatic as part of environments
-
Testing
Test execution with known best practices
-
Static analysis
Static analysis backed by Ruff with up-to-date, sane defaults
-
Script runner
Execute Python scripts with specific dependencies and Python versions
-
Publishing
Easily upload to PyPI or other indices
-
Versioning
Streamlined workflow for bumping versions
-
Project generation
Create new projects from templates with known best practices
-
Responsive CLI
Hatch is up to 3x faster than equivalent tools
License¶
Hatch is distributed under the terms of the MIT license.
Navigation¶
Documentation for specific MAJOR.MINOR versions can be chosen by using the dropdown on the top of every page. The dev version reflects changes that have not yet been released.
Also, desktop readers can use special keyboard shortcuts:
| Keys | Action |
|---|---|
| Navigate to the "previous" page |
| Navigate to the "next" page |
| Display the search modal |
Installation¶
GitHub Actions¶
- name: Install Hatch
+ uses: pypa/hatch@install
+Refer to the official action for more information.
Installers¶
- In your browser, download the
.pkgfile: hatch-universal.pkg - Run your downloaded file and follow the on-screen instructions.
- Restart your terminal.
-
To verify that the shell can find and run the
hatchcommand in yourPATH, use the following command.$ hatch --version +1.13.0 +
-
Download the file using the
curlcommand. The-ooption specifies the file name that the downloaded package is written to. In this example, the file is written tohatch-universal.pkgin the current directory.curl -Lo hatch-universal.pkg https://github.com/pypa/hatch/releases/latest/download/hatch-universal.pkg + -
Run the standard macOS
installerprogram, specifying the downloaded.pkgfile as the source. Use the-pkgparameter to specify the name of the package to install, and the-target /parameter for the drive in which to install the package. The files are installed to/usr/local/hatch, and an entry is created at/etc/paths.d/hatchthat instructs shells to add the/usr/local/hatchdirectory to. You must include sudo on the command to grant write permissions to those folders.sudo installer -pkg ./hatch-universal.pkg -target / + -
Restart your terminal.
-
To verify that the shell can find and run the
hatchcommand in yourPATH, use the following command.$ hatch --version +1.13.0 +
- In your browser, download one the
.msifiles: - Run your downloaded file and follow the on-screen instructions.
- Restart your terminal.
-
To verify that the shell can find and run the
hatchcommand in yourPATH, use the following command.$ hatch --version +1.13.0 +
-
Download and run the installer using the standard Windows
msiexecprogram, specifying one of the.msifiles as the source. Use the/passiveand/iparameters to request an unattended, normal installation.msiexec /passive /i https://github.com/pypa/hatch/releases/latest/download/hatch-x64.msi +msiexec /passive /i https://github.com/pypa/hatch/releases/latest/download/hatch-x86.msi + -
Restart your terminal.
-
To verify that the shell can find and run the
hatchcommand in yourPATH, use the following command.$ hatch --version +1.13.0 +
Standalone binaries¶
After downloading the archive corresponding to your platform and architecture, extract the binary to a directory that is on your PATH and rename to hatch.
pip¶
Hatch is available on PyPI and can be installed with pip.
pip install hatch
+Warning
This method modifies the Python environment in which you choose to install. Consider instead using pipx to avoid dependency conflicts.
pipx¶
pipx allows for the global installation of Python applications in isolated environments.
pipx install hatch
+Homebrew¶
See the formula for more details.
brew install hatch
+Conda¶
See the feedstock for more details.
conda install -c conda-forge hatch
+or with mamba:
mamba install hatch
+Warning
This method modifies the Conda environment in which you choose to install. Consider instead using pipx or condax to avoid dependency conflicts.
MacPorts¶
See the port for more details.
sudo port install hatch
+Fedora¶
The minimum supported version is 37, currently in development as Rawhide.
sudo dnf install hatch
+Void Linux¶
xbps-install hatch
+Build system availability¶
Hatchling is Hatch's build backend which you will never need to install manually. See its changelog for version information.
Introduction¶
Setup¶
Projects can be set up for use by Hatch using the new command.
New project¶
Let's say you want to create a project named Hatch Demo. You would run:
hatch new "Hatch Demo"
+This would create the following structure in your current working directory:
hatch-demo
+├── src
+│ └── hatch_demo
+│ ├── __about__.py
+│ └── __init__.py
+├── tests
+│ └── __init__.py
+├── LICENSE.txt
+├── README.md
+└── pyproject.toml
+Tip
There are many ways to customize project generation.
Existing project¶
To initialize an existing project, enter the directory containing the project and run the following:
hatch new --init
+If your project has a setup.py file the command will automatically migrate setuptools configuration for you. Otherwise, this will interactively guide you through the setup process.
Project metadata¶
Next you'll want to define more of your project's metadata located in the pyproject.toml file. You can specify things like its license, the supported versions of Python, and URLs referring to various parts of your project, like documentation.
Dependencies¶
The last step of the setup process is to define any dependencies that you'd like your project to begin with.
Configuration¶
All project-specific configuration recognized by Hatch can be defined in either the pyproject.toml file, or a file named hatch.toml where options are not contained within the tool.hatch table:
[tool.hatch]
+option = "..."
+
+[tool.hatch.table1]
+option = "..."
+
+[tool.hatch.table2]
+option = "..."
+option = "..."
+
+[table1]
+option = "..."
+
+[table2]
+option = "..."
+Top level keys in the latter file take precedence when defined in both.
Tip
If you want to make your file more compact, you can use dotted keys, turning the above example into:
[tool.hatch]
+option = "..."
+table1.option = "..."
+table2.option = "..."
+option = "..."
+table1.option = "..."
+table2.option = "..."
+FAQ¶
Interoperability¶
Q: What is the risk of lock-in?
A: Not much! Other than the plugin system, everything uses Python's established standards by default. Project metadata is based entirely on the standard, the build system is compatible with PEP 517/PEP 660, versioning uses the scheme specified by PEP 440, dependencies are defined with PEP 508 strings, and environments use virtualenv.
Q: Must one use all features?
A: No, all features are optional! You can use just the build system, publish wheels and source distributions that were built by other tools, only use the environment management, etc.
Libraries vs applications¶
Q: Are workflows for both libraries and applications supported?
A: Yes, mostly! Applications can utilize environment management just like libraries, and plugins can be used to build projects in arbitrary formats or publish artifacts to arbitrary destinations.
The only caveat is that currently there is no support for re-creating an environment given a set of dependencies in a reproducible manner. Although a standard lock file format may be far off since PEP 665 was rejected, resolving capabilities are coming to pip. When that is stabilized, Hatch will add locking functionality and dedicated documentation for managing applications.
Tool migration¶
Q: How to migrate to Hatch?
Build system¶
import os
+from io import open
+
+from setuptools import find_packages, setup
+
+about = {}
+with open(os.path.join('src', 'foo', '__about__.py'), 'r', 'utf-8') as f:
+ exec(f.read(), about)
+
+with open('README.md', 'r', 'utf-8') as f:
+ readme = f.read()
+
+setup(
+ # Metadata
+ name='foo',
+ version=about['__version__'],
+ description='...',
+ long_description=readme,
+ long_description_content_type='text/markdown',
+ author='...',
+ author_email='...',
+ project_urls={
+ 'Documentation': '...',
+ 'Source': '...',
+ },
+ classifiers=[
+ '...',
+ ],
+ keywords=[
+ '...',
+ ],
+ python_requires='>=3.8',
+ install_requires=[
+ '...',
+ ],
+ extras_require={
+ 'feature': ['...'],
+ },
+
+ # Packaging
+ packages=find_packages(where='src'),
+ package_dir={'': 'src'},
+ package_data={
+ 'foo': ['py.typed'],
+ },
+ zip_safe=False,
+ entry_points={
+ 'console_scripts': [
+ 'foo = foo.cli:main',
+ ],
+ },
+)
+graft tests
+
+global-exclude *.py[cod] __pycache__
+[build-system]
+requires = ["hatchling"]
+build-backend = "hatchling.build"
+
+[project]
+name = "foo"
+description = "..."
+readme = "README.md"
+authors = [
+ { name = "...", email = "..." },
+]
+classifiers = [
+ "...",
+]
+keywords = [
+ "...",
+]
+requires-python = ">=3.8"
+dependencies = [
+ "...",
+]
+dynamic = ["version"]
+
+[project.urls]
+Documentation = "..."
+Source = "..."
+
+[project.optional-dependencies]
+feature = ["..."]
+
+[project.scripts]
+foo = "foo.cli:main"
+
+[tool.hatch.version]
+path = "src/foo/__about__.py"
+
+[tool.hatch.build.targets.sdist]
+include = [
+ "/src",
+ "/tests",
+]
+Environments¶
Invocation:
tox
+[tox]
+envlist =
+ py{38,39}-{42,3.14}
+ py{39,310}-{9000}-{foo,bar}
+
+[testenv]
+usedevelop = true
+deps =
+ coverage[toml]
+ pytest
+ pytest-cov
+ foo: cryptography
+commands =
+ pytest --cov-report=term-missing --cov-config=pyproject.toml --cov=pkg --cov=tests {posargs}
+setenv =
+ 3.14: PRODUCT_VERSION=3.14
+ 42: PRODUCT_VERSION=42
+ 9000: PRODUCT_VERSION=9000
+ {foo,bar}: EXPERIMENTAL=true
+Invocation:
hatch run test
+[tool.hatch.envs.default]
+dependencies = [
+ "coverage[toml]",
+ "pytest",
+ "pytest-cov",
+]
+
+[tool.hatch.envs.default.scripts]
+test = 'pytest --cov-report=term-missing --cov-config=pyproject.toml --cov=pkg --cov=tests'
+
+[tool.hatch.envs.default.overrides]
+matrix.version.env-vars = "PRODUCT_VERSION"
+matrix.feature.env-vars = "EXPERIMENTAL=true"
+matrix.feature.dependencies = [
+ { value = "cryptography", if = ["foo"] },
+]
+
+[[tool.hatch.envs.default.matrix]]
+python = ["3.8", "3.9"]
+version = ["42", "3.14"]
+
+[[tool.hatch.envs.default.matrix]]
+python = ["3.9", "3.10"]
+version = ["9000"]
+feature = ["foo", "bar"]
+[envs.default]
+dependencies = [
+ "coverage[toml]",
+ "pytest",
+ "pytest-cov",
+]
+
+[envs.default.scripts]
+test = 'pytest --cov-report=term-missing --cov-config=pyproject.toml --cov=pkg --cov=tests'
+
+[envs.default.overrides]
+matrix.version.env-vars = "PRODUCT_VERSION"
+matrix.feature.env-vars = "EXPERIMENTAL=true"
+matrix.feature.dependencies = [
+ { value = "cryptography", if = ["foo"] },
+]
+
+[[envs.default.matrix]]
+python = ["3.8", "3.9"]
+version = ["42", "3.14"]
+
+[[envs.default.matrix]]
+python = ["3.9", "3.10"]
+version = ["9000"]
+feature = ["foo", "bar"]
+Fast CLI?¶
The claim about being faster than other tools is based on timings that are always checked in CI.
Hatch achieves this by using lazy imports, lazily performing computation manually and with functools.cached_property, using hacks like not not ... instead of bool(...), etc.
Next steps¶
Learn more¶
At this point you should have a basic understanding of how to use Hatch.
Now you may want to check out advanced configuration for environments or builds, set up your preferred shell, or read more about Hatch's CLI.
After that, check out the Hatch Showcase project to see examples of what is possible.
Finally, if you see a need, feel free to write a plugin for extended functionality.
Community¶
For any projects using Hatch, you may add its official badge somewhere prominent like the README.
[](https://github.com/pypa/hatch)
+.. image:: https://img.shields.io/badge/%F0%9F%A5%9A-Hatch-4051b5.svg
+ :alt: Hatch project
+ :target: https://github.com/pypa/hatch
+Plugins¶
Hatch utilizes pluggy for its plugin functionality.
Overview¶
All plugins provide registration hooks that return one or more classes that inherit from a particular type interface.
Each registration hook must be decorated by Hatch's hook marker. For example, if you wanted to create a new kind of environment you could do:
from hatchling.plugin import hookimpl
+
+from .plugin import SpecialEnvironment
+
+
+@hookimpl
+def hatch_register_environment():
+ return SpecialEnvironment
+The hooks can return a single class or a list of classes.
Every class must define an attribute called PLUGIN_NAME that users will select when they wish to use the plugin. So in the example above, the class might be defined like:
...
+class SpecialEnvironment(...):
+ PLUGIN_NAME = 'special'
+ ...
+Project configuration¶
Naming¶
It is recommended that plugin project names are prefixed with hatch-. For example, if you wanted to make a plugin that provides some functionality for a product named foo you might do:
[project]
+name = "hatch-foo"
+Discovery¶
You'll need to define your project as a Python plugin for Hatch:
[project.entry-points.hatch]
+foo = "pkg.hooks"
+The name of the plugin should be the project name (excluding any hatch- prefix) and the path should represent the module that contains the registration hooks.
Classifier¶
Add Framework :: Hatch to your project's classifiers to make it easy to search for Hatch plugins:
[project]
+classifiers = [
+ ...
+ "Framework :: Hatch",
+ ...
+]
+Types¶
Hatchling¶
These are all involved in building projects and therefore any defined dependencies are automatically installed in each build environment.
Hatch¶
These must be installed in the same environment as Hatch itself.
Custom build hook¶
This is a custom class in a given Python file that inherits from the BuildHookInterface.
Configuration¶
The build hook plugin name is custom.
[tool.hatch.build.hooks.custom]
+[tool.hatch.build.targets.<TARGET_NAME>.hooks.custom]
+[build.hooks.custom]
+[build.targets.<TARGET_NAME>.hooks.custom]
+Options¶
| Option | Default | Description |
|---|---|---|
path | hatch_build.py | The path of the Python file |
Example¶
from hatchling.builders.hooks.plugin.interface import BuildHookInterface
+
+
+class CustomBuildHook(BuildHookInterface):
+ ...
+If multiple subclasses are found, you must define a function named get_build_hook that returns the desired build hook.
Note
Any defined PLUGIN_NAME is ignored and will always be custom.
Build hook plugins¶
A build hook provides code that will be executed at various stages of the build process. See the documentation for build hook configuration.
Known third-party¶
- hatch-argparse-manpage - generate man pages for argparse-based CLIs
- hatch-autorun - used to inject code into an installation that will automatically run before the first import
- hatch-build-scripts - run arbitrary shell commands that create artifacts
- hatch-cython - build Cython extensions
- hatch-gettext - compiles multi-lingual messages with GNU
gettexttools - hatch-jupyter-builder - used for packages in the Project Jupyter ecosystem
- hatch-mypyc - compiles code with Mypyc
- hatch-odoo - package Odoo add-ons into the appropriate namespace
- scikit-build-core - build extension modules with CMake
Overview¶
Build hooks run for every selected version of build targets.
The initialization stage occurs immediately before each build and the finalization stage occurs immediately after. Each stage has the opportunity to view or modify build data.
Build data¶
Build data is a simple mapping whose contents can influence the behavior of builds. Which fields exist and are recognized depends on each build target.
The following fields are always present and recognized by the build system itself:
| Field | Type | Description |
|---|---|---|
artifacts | list[str] | This is a list of extra artifact patterns and should generally only be appended to |
force_include | dict[str, str] | This is a mapping of extra forced inclusion paths, with this mapping taking precedence in case of conflicts |
build_hooks | tuple[str, ...] | This is an immutable sequence of the names of the configured build hooks and matches the order in which they run |
Attention
While user-facing TOML options are hyphenated, build data fields should be named with underscores to allow plugins to use them as valid Python identifiers.
Notes¶
In some cases it may be necessary to use force_include rather than artifacts. For example, say that you want to install a lib.so directly at the root of site-packages and a project defines a package src/foo. If you create src/lib.so, there will never be a match because the directory traversal starts at src/foo rather than src. In that case you must do either:
build_data['force_include']['src/lib.so'] = 'src/lib.so'
+or
build_data['force_include']['/absolute/path/to/src/lib.so'] = 'src/lib.so'
+ BuildHookInterface ¶
Example usage:
from hatchling.builders.hooks.plugin.interface import BuildHookInterface
+
+
+class SpecialBuildHook(BuildHookInterface):
+ PLUGIN_NAME = 'special'
+ ...
+from hatchling.plugin import hookimpl
+
+from .plugin import SpecialBuildHook
+
+
+@hookimpl
+def hatch_register_build_hook():
+ return SpecialBuildHook
+Source code in backend/src/hatchling/builders/hooks/plugin/interface.py
class BuildHookInterface(Generic[BuilderConfigBound]): # no cov
+ """
+ Example usage:
+
+ ```python tab="plugin.py"
+ from hatchling.builders.hooks.plugin.interface import BuildHookInterface
+
+
+ class SpecialBuildHook(BuildHookInterface):
+ PLUGIN_NAME = 'special'
+ ...
+ ```
+
+ ```python tab="hooks.py"
+ from hatchling.plugin import hookimpl
+
+ from .plugin import SpecialBuildHook
+
+
+ @hookimpl
+ def hatch_register_build_hook():
+ return SpecialBuildHook
+ ```
+ """
+
+ PLUGIN_NAME = ''
+ """The name used for selection."""
+
+ def __init__(
+ self,
+ root: str,
+ config: dict[str, Any],
+ build_config: BuilderConfigBound,
+ metadata: ProjectMetadata,
+ directory: str,
+ target_name: str,
+ app: Application | None = None,
+ ) -> None:
+ self.__root = root
+ self.__config = config
+ self.__build_config = build_config
+ self.__metadata = metadata
+ self.__directory = directory
+ self.__target_name = target_name
+ self.__app = app
+
+ @property
+ def app(self) -> Application:
+ """
+ An instance of [Application](../utilities.md#hatchling.bridge.app.Application).
+ """
+ if self.__app is None:
+ from hatchling.bridge.app import Application
+
+ self.__app = cast(Application, Application().get_safe_application())
+
+ return self.__app
+
+ @property
+ def root(self) -> str:
+ """
+ The root of the project tree.
+ """
+ return self.__root
+
+ @property
+ def config(self) -> dict[str, Any]:
+ """
+ The cumulative hook configuration.
+
+ ```toml config-example
+ [tool.hatch.build.hooks.<PLUGIN_NAME>]
+ [tool.hatch.build.targets.<TARGET_NAME>.hooks.<PLUGIN_NAME>]
+ ```
+ """
+ return self.__config
+
+ @property
+ def metadata(self) -> ProjectMetadata:
+ # Undocumented for now
+ return self.__metadata
+
+ @property
+ def build_config(self) -> BuilderConfigBound:
+ """
+ An instance of [BuilderConfig](../utilities.md#hatchling.builders.config.BuilderConfig).
+ """
+ return self.__build_config
+
+ @property
+ def directory(self) -> str:
+ """
+ The build directory.
+ """
+ return self.__directory
+
+ @property
+ def target_name(self) -> str:
+ """
+ The plugin name of the build target.
+ """
+ return self.__target_name
+
+ def dependencies(self) -> list[str]: # noqa: PLR6301
+ """
+ A list of extra [dependencies](../../config/dependency.md) that must be installed
+ prior to builds.
+
+ !!! warning
+ - For this to have any effect the hook dependency itself cannot be dynamic and
+ must always be defined in `build-system.requires`.
+ - As the hook must be imported to call this method, imports that require these
+ dependencies must be evaluated lazily.
+ """
+ return []
+
+ def clean(self, versions: list[str]) -> None:
+ """
+ This occurs before the build process if the `-c`/`--clean` flag was passed to
+ the [`build`](../../cli/reference.md#hatch-build) command, or when invoking
+ the [`clean`](../../cli/reference.md#hatch-clean) command.
+ """
+
+ def initialize(self, version: str, build_data: dict[str, Any]) -> None:
+ """
+ This occurs immediately before each build.
+
+ Any modifications to the build data will be seen by the build target.
+ """
+
+ def finalize(self, version: str, build_data: dict[str, Any], artifact_path: str) -> None:
+ """
+ This occurs immediately after each build and will not run if the `--hooks-only` flag
+ was passed to the [`build`](../../cli/reference.md#hatch-build) command.
+
+ The build data will reflect any modifications done by the target during the build.
+ """
+ PLUGIN_NAME = '' class-attribute instance-attribute ¶
The name used for selection.
app: Application property ¶
An instance of Application.
root: str property ¶
The root of the project tree.
config: dict[str, Any] property ¶
The cumulative hook configuration.
[tool.hatch.build.hooks.<PLUGIN_NAME>]
+[tool.hatch.build.targets.<TARGET_NAME>.hooks.<PLUGIN_NAME>]
+[build.hooks.<PLUGIN_NAME>]
+[build.targets.<TARGET_NAME>.hooks.<PLUGIN_NAME>]
+ build_config: BuilderConfigBound property ¶
An instance of BuilderConfig.
target_name: str property ¶
The plugin name of the build target.
directory: str property ¶
The build directory.
dependencies() -> list[str] ¶
A list of extra dependencies that must be installed prior to builds.
Warning
- For this to have any effect the hook dependency itself cannot be dynamic and must always be defined in
build-system.requires. - As the hook must be imported to call this method, imports that require these dependencies must be evaluated lazily.
Source code in backend/src/hatchling/builders/hooks/plugin/interface.py
def dependencies(self) -> list[str]: # noqa: PLR6301
+ """
+ A list of extra [dependencies](../../config/dependency.md) that must be installed
+ prior to builds.
+
+ !!! warning
+ - For this to have any effect the hook dependency itself cannot be dynamic and
+ must always be defined in `build-system.requires`.
+ - As the hook must be imported to call this method, imports that require these
+ dependencies must be evaluated lazily.
+ """
+ return []
+ clean(versions: list[str]) -> None ¶
This occurs before the build process if the -c/--clean flag was passed to the build command, or when invoking the clean command.
Source code in backend/src/hatchling/builders/hooks/plugin/interface.py
def clean(self, versions: list[str]) -> None:
+ """
+ This occurs before the build process if the `-c`/`--clean` flag was passed to
+ the [`build`](../../cli/reference.md#hatch-build) command, or when invoking
+ the [`clean`](../../cli/reference.md#hatch-clean) command.
+ """
+ initialize(version: str, build_data: dict[str, Any]) -> None ¶
This occurs immediately before each build.
Any modifications to the build data will be seen by the build target.
Source code in backend/src/hatchling/builders/hooks/plugin/interface.py
def initialize(self, version: str, build_data: dict[str, Any]) -> None:
+ """
+ This occurs immediately before each build.
+
+ Any modifications to the build data will be seen by the build target.
+ """
+ finalize(version: str, build_data: dict[str, Any], artifact_path: str) -> None ¶
This occurs immediately after each build and will not run if the --hooks-only flag was passed to the build command.
The build data will reflect any modifications done by the target during the build.
Source code in backend/src/hatchling/builders/hooks/plugin/interface.py
def finalize(self, version: str, build_data: dict[str, Any], artifact_path: str) -> None:
+ """
+ This occurs immediately after each build and will not run if the `--hooks-only` flag
+ was passed to the [`build`](../../cli/reference.md#hatch-build) command.
+
+ The build data will reflect any modifications done by the target during the build.
+ """
+Version build hook¶
This writes the project's version to a file.
Configuration¶
The build hook plugin name is version.
[tool.hatch.build.hooks.version]
+[tool.hatch.build.targets.<TARGET_NAME>.hooks.version]
+[build.hooks.version]
+[build.targets.<TARGET_NAME>.hooks.version]
+Options¶
| Option | Description |
|---|---|
path (required) | A relative path to the desired file |
template | A string representing the entire contents of path that will be formatted with a version variable |
pattern | Rather than updating the entire file, a regular expression may be used that has a named group called version that represents the version. If set to true, a pattern will be used that looks for a variable named __version__ or VERSION that is set to a string containing the version, optionally prefixed with the lowercase letter v. |
Binary builder¶
This uses PyApp to build an application that is able to bootstrap itself at runtime.
Note
This requires an installation of Rust.
Configuration¶
The builder plugin name is binary.
[tool.hatch.build.targets.binary]
+[build.targets.binary]
+Options¶
| Option | Default | Description |
|---|---|---|
scripts | all defined | An array of defined script names to limit what gets built |
python-version | latest compatible Python minor version | The Python version ID to use |
pyapp-version | The version of PyApp to use |
Build behavior¶
If any scripts are defined then each one will be built (limited by the scripts option). Otherwise, a single executable will be built based on the project name assuming there is an equivalently named module with a __main__.py file.
Every executable will be built inside an app directory in the output directory.
If the CARGO environment variable is set then that path will be used as the executable for performing builds.
If the CARGO_BUILD_TARGET environment variable is set then its value will be appended to the file name stems.
If the PYAPP_REPO environment variable is set then a local build will be performed inside that directory rather than installing from crates.io. Note that this is required if the CARGO environment variable refers to cross.
Custom builder¶
This is a custom class in a given Python file that inherits from the BuilderInterface.
Configuration¶
The builder plugin name is custom.
[tool.hatch.build.targets.custom]
+[build.targets.custom]
+Options¶
| Option | Default | Description |
|---|---|---|
path | hatch_build.py | The path of the Python file |
Example¶
from hatchling.builders.plugin.interface import BuilderInterface
+
+
+class CustomBuilder(BuilderInterface):
+ ...
+If multiple subclasses are found, you must define a function named get_builder that returns the desired builder.
Note
Any defined PLUGIN_NAME is ignored and will always be custom.
Builder plugins¶
See the documentation for build configuration.
Known third-party¶
- hatch-aws - used for building AWS Lambda functions with SAM
- hatch-zipped-directory - used for building ZIP archives for installation into various foreign package installation systems
BuilderInterface ¶
Example usage:
from hatchling.builders.plugin.interface import BuilderInterface
+
+
+class SpecialBuilder(BuilderInterface):
+ PLUGIN_NAME = 'special'
+ ...
+from hatchling.plugin import hookimpl
+
+from .plugin import SpecialBuilder
+
+
+@hookimpl
+def hatch_register_builder():
+ return SpecialBuilder
+Source code in backend/src/hatchling/builders/plugin/interface.py
class BuilderInterface(ABC, Generic[BuilderConfigBound, PluginManagerBound]):
+ """
+ Example usage:
+
+ ```python tab="plugin.py"
+ from hatchling.builders.plugin.interface import BuilderInterface
+
+
+ class SpecialBuilder(BuilderInterface):
+ PLUGIN_NAME = 'special'
+ ...
+ ```
+
+ ```python tab="hooks.py"
+ from hatchling.plugin import hookimpl
+
+ from .plugin import SpecialBuilder
+
+
+ @hookimpl
+ def hatch_register_builder():
+ return SpecialBuilder
+ ```
+ """
+
+ PLUGIN_NAME = ''
+ """The name used for selection."""
+
+ def __init__(
+ self,
+ root: str,
+ plugin_manager: PluginManagerBound | None = None,
+ config: dict[str, Any] | None = None,
+ metadata: ProjectMetadata | None = None,
+ app: Application | None = None,
+ ) -> None:
+ self.__root = root
+ self.__plugin_manager = cast(PluginManagerBound, plugin_manager)
+ self.__raw_config = config
+ self.__metadata = metadata
+ self.__app = app
+ self.__config = cast(BuilderConfigBound, None)
+ self.__project_config: dict[str, Any] | None = None
+ self.__hatch_config: dict[str, Any] | None = None
+ self.__build_config: dict[str, Any] | None = None
+ self.__build_targets: list[str] | None = None
+ self.__target_config: dict[str, Any] | None = None
+
+ # Metadata
+ self.__project_id: str | None = None
+
+ def build(
+ self,
+ *,
+ directory: str | None = None,
+ versions: list[str] | None = None,
+ hooks_only: bool | None = None,
+ clean: bool | None = None,
+ clean_hooks_after: bool | None = None,
+ clean_only: bool | None = False,
+ ) -> Generator[str, None, None]:
+ # Fail early for invalid project metadata
+ self.metadata.validate_fields()
+
+ if directory is None:
+ directory = (
+ self.config.normalize_build_directory(os.environ[BuildEnvVars.LOCATION])
+ if BuildEnvVars.LOCATION in os.environ
+ else self.config.directory
+ )
+
+ if not os.path.isdir(directory):
+ os.makedirs(directory)
+
+ version_api = self.get_version_api()
+
+ versions = versions or self.config.versions
+ if versions:
+ unknown_versions = set(versions) - set(version_api)
+ if unknown_versions:
+ message = (
+ f'Unknown versions for target `{self.PLUGIN_NAME}`: {", ".join(map(str, sorted(unknown_versions)))}'
+ )
+ raise ValueError(message)
+
+ if hooks_only is None:
+ hooks_only = env_var_enabled(BuildEnvVars.HOOKS_ONLY)
+
+ configured_build_hooks = self.get_build_hooks(directory)
+ build_hooks = list(configured_build_hooks.values())
+
+ if clean_only:
+ clean = True
+ elif clean is None:
+ clean = env_var_enabled(BuildEnvVars.CLEAN)
+ if clean:
+ if not hooks_only:
+ self.clean(directory, versions)
+
+ for build_hook in build_hooks:
+ build_hook.clean(versions)
+
+ if clean_only:
+ return
+
+ if clean_hooks_after is None:
+ clean_hooks_after = env_var_enabled(BuildEnvVars.CLEAN_HOOKS_AFTER)
+
+ for version in versions:
+ self.app.display_debug(f'Building `{self.PLUGIN_NAME}` version `{version}`')
+
+ build_data = self.get_default_build_data()
+ self.set_build_data_defaults(build_data)
+
+ # Allow inspection of configured build hooks and the order in which they run
+ build_data['build_hooks'] = tuple(configured_build_hooks)
+
+ # Execute all `initialize` build hooks
+ for build_hook in build_hooks:
+ build_hook.initialize(version, build_data)
+
+ if hooks_only:
+ self.app.display_debug(f'Only ran build hooks for `{self.PLUGIN_NAME}` version `{version}`')
+ continue
+
+ # Build the artifact
+ with self.config.set_build_data(build_data):
+ artifact = version_api[version](directory, **build_data)
+
+ # Execute all `finalize` build hooks
+ for build_hook in build_hooks:
+ build_hook.finalize(version, build_data, artifact)
+
+ if clean_hooks_after:
+ for build_hook in build_hooks:
+ build_hook.clean([version])
+
+ yield artifact
+
+ def recurse_included_files(self) -> Iterable[IncludedFile]:
+ """
+ Returns a consistently generated series of file objects for every file that should be distributed. Each file
+ object has three `str` attributes:
+
+ - `path` - the absolute path
+ - `relative_path` - the path relative to the project root; will be an empty string for external files
+ - `distribution_path` - the path to be distributed as
+ """
+ yield from self.recurse_selected_project_files()
+ yield from self.recurse_forced_files(self.config.get_force_include())
+
+ def recurse_selected_project_files(self) -> Iterable[IncludedFile]:
+ if self.config.only_include:
+ yield from self.recurse_explicit_files(self.config.only_include)
+ else:
+ yield from self.recurse_project_files()
+
+ def recurse_project_files(self) -> Iterable[IncludedFile]:
+ for root, dirs, files in safe_walk(self.root):
+ relative_path = get_relative_path(root, self.root)
+
+ dirs[:] = sorted(d for d in dirs if not self.config.directory_is_excluded(d, relative_path))
+
+ files.sort()
+ is_package = '__init__.py' in files
+ for f in files:
+ if f in EXCLUDED_FILES:
+ continue
+
+ relative_file_path = os.path.join(relative_path, f)
+ distribution_path = self.config.get_distribution_path(relative_file_path)
+ if self.config.path_is_reserved(distribution_path):
+ continue
+
+ if self.config.include_path(relative_file_path, is_package=is_package):
+ yield IncludedFile(
+ os.path.join(root, f), relative_file_path, self.config.get_distribution_path(relative_file_path)
+ )
+
+ def recurse_forced_files(self, inclusion_map: dict[str, str]) -> Iterable[IncludedFile]:
+ for source, target_path in inclusion_map.items():
+ external = not source.startswith(self.root)
+ if os.path.isfile(source):
+ yield IncludedFile(
+ source,
+ '' if external else os.path.relpath(source, self.root),
+ self.config.get_distribution_path(target_path),
+ )
+ elif os.path.isdir(source):
+ for root, dirs, files in safe_walk(source):
+ relative_directory = get_relative_path(root, source)
+
+ dirs[:] = sorted(d for d in dirs if d not in EXCLUDED_DIRECTORIES)
+
+ files.sort()
+ for f in files:
+ if f in EXCLUDED_FILES:
+ continue
+
+ relative_file_path = os.path.join(target_path, relative_directory, f)
+ distribution_path = self.config.get_distribution_path(relative_file_path)
+ if not self.config.path_is_reserved(distribution_path):
+ yield IncludedFile(
+ os.path.join(root, f),
+ '' if external else relative_file_path,
+ distribution_path,
+ )
+ else:
+ msg = f'Forced include not found: {source}'
+ raise FileNotFoundError(msg)
+
+ def recurse_explicit_files(self, inclusion_map: dict[str, str]) -> Iterable[IncludedFile]:
+ for source, target_path in inclusion_map.items():
+ external = not source.startswith(self.root)
+ if os.path.isfile(source):
+ distribution_path = self.config.get_distribution_path(target_path)
+ if not self.config.path_is_reserved(distribution_path):
+ yield IncludedFile(
+ source,
+ '' if external else os.path.relpath(source, self.root),
+ self.config.get_distribution_path(target_path),
+ )
+ elif os.path.isdir(source):
+ for root, dirs, files in safe_walk(source):
+ relative_directory = get_relative_path(root, source)
+
+ dirs[:] = sorted(d for d in dirs if d not in EXCLUDED_DIRECTORIES)
+
+ files.sort()
+ is_package = '__init__.py' in files
+ for f in files:
+ if f in EXCLUDED_FILES:
+ continue
+
+ relative_file_path = os.path.join(target_path, relative_directory, f)
+ distribution_path = self.config.get_distribution_path(relative_file_path)
+ if self.config.path_is_reserved(distribution_path):
+ continue
+
+ if self.config.include_path(relative_file_path, explicit=True, is_package=is_package):
+ yield IncludedFile(
+ os.path.join(root, f), '' if external else relative_file_path, distribution_path
+ )
+
+ @property
+ def root(self) -> str:
+ """
+ The root of the project tree.
+ """
+ return self.__root
+
+ @property
+ def plugin_manager(self) -> PluginManagerBound:
+ if self.__plugin_manager is None:
+ from hatchling.plugin.manager import PluginManager
+
+ self.__plugin_manager = PluginManager()
+
+ return self.__plugin_manager
+
+ @property
+ def metadata(self) -> ProjectMetadata:
+ if self.__metadata is None:
+ from hatchling.metadata.core import ProjectMetadata
+
+ self.__metadata = ProjectMetadata(self.root, self.plugin_manager, self.__raw_config)
+
+ return self.__metadata
+
+ @property
+ def app(self) -> Application:
+ """
+ An instance of [Application](../utilities.md#hatchling.bridge.app.Application).
+ """
+ if self.__app is None:
+ from hatchling.bridge.app import Application
+
+ self.__app = cast(Application, Application().get_safe_application())
+
+ return self.__app
+
+ @property
+ def raw_config(self) -> dict[str, Any]:
+ if self.__raw_config is None:
+ self.__raw_config = self.metadata.config
+
+ return self.__raw_config
+
+ @property
+ def project_config(self) -> dict[str, Any]:
+ if self.__project_config is None:
+ self.__project_config = self.metadata.core.config
+
+ return self.__project_config
+
+ @property
+ def hatch_config(self) -> dict[str, Any]:
+ if self.__hatch_config is None:
+ self.__hatch_config = self.metadata.hatch.config
+
+ return self.__hatch_config
+
+ @property
+ def config(self) -> BuilderConfigBound:
+ """
+ An instance of [BuilderConfig](../utilities.md#hatchling.builders.config.BuilderConfig).
+ """
+ if self.__config is None:
+ self.__config = self.get_config_class()(
+ self, self.root, self.PLUGIN_NAME, self.build_config, self.target_config
+ )
+
+ return self.__config
+
+ @property
+ def build_config(self) -> dict[str, Any]:
+ """
+ ```toml config-example
+ [tool.hatch.build]
+ ```
+ """
+ if self.__build_config is None:
+ self.__build_config = self.metadata.hatch.build_config
+
+ return self.__build_config
+
+ @property
+ def target_config(self) -> dict[str, Any]:
+ """
+ ```toml config-example
+ [tool.hatch.build.targets.<PLUGIN_NAME>]
+ ```
+ """
+ if self.__target_config is None:
+ target_config: dict[str, Any] = self.metadata.hatch.build_targets.get(self.PLUGIN_NAME, {})
+ if not isinstance(target_config, dict):
+ message = f'Field `tool.hatch.build.targets.{self.PLUGIN_NAME}` must be a table'
+ raise TypeError(message)
+
+ self.__target_config = target_config
+
+ return self.__target_config
+
+ @property
+ def project_id(self) -> str:
+ if self.__project_id is None:
+ self.__project_id = f'{self.normalize_file_name_component(self.metadata.core.name)}-{self.metadata.version}'
+
+ return self.__project_id
+
+ def get_build_hooks(self, directory: str) -> dict[str, BuildHookInterface]:
+ configured_build_hooks = {}
+ for hook_name, config in self.config.hook_config.items():
+ build_hook = self.plugin_manager.build_hook.get(hook_name)
+ if build_hook is None:
+ from hatchling.plugin.exceptions import UnknownPluginError
+
+ message = f'Unknown build hook: {hook_name}'
+ raise UnknownPluginError(message)
+
+ configured_build_hooks[hook_name] = build_hook(
+ self.root, config, self.config, self.metadata, directory, self.PLUGIN_NAME, self.app
+ )
+
+ return configured_build_hooks
+
+ @abstractmethod
+ def get_version_api(self) -> dict[str, Callable]:
+ """
+ A mapping of `str` versions to a callable that is used for building.
+ Each callable must have the following signature:
+
+ ```python
+ def ...(build_dir: str, build_data: dict) -> str:
+ ```
+
+ The return value must be the absolute path to the built artifact.
+ """
+
+ def get_default_versions(self) -> list[str]:
+ """
+ A list of versions to build when users do not specify any, defaulting to all versions.
+ """
+ return list(self.get_version_api())
+
+ def get_default_build_data(self) -> dict[str, Any]: # noqa: PLR6301
+ """
+ A mapping that can be modified by [build hooks](../build-hook/reference.md) to influence the behavior of builds.
+ """
+ return {}
+
+ def set_build_data_defaults(self, build_data: dict[str, Any]) -> None: # noqa: PLR6301
+ build_data.setdefault('artifacts', [])
+ build_data.setdefault('force_include', {})
+
+ def clean(self, directory: str, versions: list[str]) -> None:
+ """
+ Called before builds if the `-c`/`--clean` flag was passed to the
+ [`build`](../../cli/reference.md#hatch-build) command.
+ """
+
+ @classmethod
+ def get_config_class(cls) -> type[BuilderConfig]:
+ """
+ Must return a subclass of [BuilderConfig](../utilities.md#hatchling.builders.config.BuilderConfig).
+ """
+ return BuilderConfig
+
+ @staticmethod
+ def normalize_file_name_component(file_name: str) -> str:
+ """
+ https://peps.python.org/pep-0427/#escaping-and-unicode
+ """
+ return re.sub(r'[^\w\d.]+', '_', file_name, flags=re.UNICODE)
+ PLUGIN_NAME = '' class-attribute instance-attribute ¶
The name used for selection.
app: Application property ¶
An instance of Application.
root: str property ¶
The root of the project tree.
build_config: dict[str, Any] property ¶
[tool.hatch.build]
+[build]
+ target_config: dict[str, Any] property ¶
[tool.hatch.build.targets.<PLUGIN_NAME>]
+[build.targets.<PLUGIN_NAME>]
+ config: BuilderConfigBound property ¶
An instance of BuilderConfig.
get_config_class() -> type[BuilderConfig] classmethod ¶
Must return a subclass of BuilderConfig.
Source code in backend/src/hatchling/builders/plugin/interface.py
@classmethod
+def get_config_class(cls) -> type[BuilderConfig]:
+ """
+ Must return a subclass of [BuilderConfig](../utilities.md#hatchling.builders.config.BuilderConfig).
+ """
+ return BuilderConfig
+ get_version_api() -> dict[str, Callable] abstractmethod ¶
A mapping of str versions to a callable that is used for building. Each callable must have the following signature:
def ...(build_dir: str, build_data: dict) -> str:
+The return value must be the absolute path to the built artifact.
Source code in backend/src/hatchling/builders/plugin/interface.py
@abstractmethod
+def get_version_api(self) -> dict[str, Callable]:
+ """
+ A mapping of `str` versions to a callable that is used for building.
+ Each callable must have the following signature:
+
+ ```python
+ def ...(build_dir: str, build_data: dict) -> str:
+ ```
+
+ The return value must be the absolute path to the built artifact.
+ """
+ get_default_versions() -> list[str] ¶
A list of versions to build when users do not specify any, defaulting to all versions.
Source code in backend/src/hatchling/builders/plugin/interface.py
def get_default_versions(self) -> list[str]:
+ """
+ A list of versions to build when users do not specify any, defaulting to all versions.
+ """
+ return list(self.get_version_api())
+ clean(directory: str, versions: list[str]) -> None ¶
Called before builds if the -c/--clean flag was passed to the build command.
Source code in backend/src/hatchling/builders/plugin/interface.py
def clean(self, directory: str, versions: list[str]) -> None:
+ """
+ Called before builds if the `-c`/`--clean` flag was passed to the
+ [`build`](../../cli/reference.md#hatch-build) command.
+ """
+ recurse_included_files() -> Iterable[IncludedFile] ¶
Returns a consistently generated series of file objects for every file that should be distributed. Each file object has three str attributes:
path- the absolute pathrelative_path- the path relative to the project root; will be an empty string for external filesdistribution_path- the path to be distributed as
Source code in backend/src/hatchling/builders/plugin/interface.py
def recurse_included_files(self) -> Iterable[IncludedFile]:
+ """
+ Returns a consistently generated series of file objects for every file that should be distributed. Each file
+ object has three `str` attributes:
+
+ - `path` - the absolute path
+ - `relative_path` - the path relative to the project root; will be an empty string for external files
+ - `distribution_path` - the path to be distributed as
+ """
+ yield from self.recurse_selected_project_files()
+ yield from self.recurse_forced_files(self.config.get_force_include())
+ get_default_build_data() -> dict[str, Any] ¶
A mapping that can be modified by build hooks to influence the behavior of builds.
Source code in backend/src/hatchling/builders/plugin/interface.py
def get_default_build_data(self) -> dict[str, Any]: # noqa: PLR6301
+ """
+ A mapping that can be modified by [build hooks](../build-hook/reference.md) to influence the behavior of builds.
+ """
+ return {}
+Source distribution builder¶
A source distribution, or sdist, is an archive of Python "source code". Although largely unspecified, by convention it should include everything that is required to build a wheel without making network requests.
Configuration¶
The builder plugin name is sdist.
[tool.hatch.build.targets.sdist]
+[build.targets.sdist]
+Options¶
| Option | Default | Description |
|---|---|---|
core-metadata-version | "2.3" | The version of core metadata to use |
strict-naming | true | Whether or not file names should contain the normalized version of the project name |
support-legacy | false | Whether or not to include a setup.py file to support legacy installation mechanisms |
Versions¶
| Version | Description |
|---|---|
standard (default) | The latest conventional format |
Default file selection¶
When the user has not set any file selection options, all files that are not ignored by your VCS will be included.
Note
The following files are always included and cannot be excluded:
/pyproject.toml/hatch.toml/hatch_build.py/.gitignoreor/.hgignore- Any defined
readmefile - All defined
license-files
Reproducibility¶
Reproducible builds are supported.
Build data¶
This is data that can be modified by build hooks.
| Data | Default | Description |
|---|---|---|
dependencies | Extra project dependencies |
Wheel builder¶
A wheel is a binary distribution of a Python package that can be installed directly into an environment.
Configuration¶
The builder plugin name is wheel.
[tool.hatch.build.targets.wheel]
+[build.targets.wheel]
+Options¶
| Option | Default | Description |
|---|---|---|
core-metadata-version | "2.3" | The version of core metadata to use |
shared-data | A mapping similar to the forced inclusion option corresponding to the data subdirectory within the standard data directory that will be installed globally in a given Python environment, usually under sys.prefix | |
shared-scripts | A mapping similar to the forced inclusion option corresponding to the scripts subdirectory within the standard data directory that will be installed in a given Python environment, usually under Scripts on Windows or bin otherwise, and would normally be available on PATH | |
extra-metadata | A mapping similar to the forced inclusion option corresponding to extra metadata that will be shipped in a directory named extra_metadata | |
strict-naming | true | Whether or not file names should contain the normalized version of the project name |
macos-max-compat | false | Whether or not on macOS, when build hooks have set the infer_tag build data, the wheel name should signal broad support rather than specific versions for newer SDK versions.Note: This option will eventually be removed. |
bypass-selection | false | Whether or not to suppress the error when one has not defined any file selection options and all heuristics have failed to determine what to ship |
Versions¶
| Version | Description |
|---|---|
standard (default) | The latest standardized format |
editable | A wheel that only ships .pth files or import hooks for real-time development |
Default file selection¶
When the user has not set any file selection options, the project name will be used to determine the package to ship in the following heuristic order:
<NAME>/__init__.pysrc/<NAME>/__init__.py<NAME>.py<NAMESPACE>/<NAME>/__init__.py
If none of these heuristics are satisfied, an error will be raised.
Reproducibility¶
Reproducible builds are supported.
Build data¶
This is data that can be modified by build hooks.
| Data | Default | Description |
|---|---|---|
tag | The full tag part of the filename (e.g. py3-none-any), defaulting to a cross-platform wheel with the supported major versions of Python based on project metadata | |
infer_tag | False | When tag is not set, this may be enabled to use the one most specific to the platform, Python interpreter, and ABI |
pure_python | True | Whether or not to write metadata indicating that the package does not contain any platform-specific files |
dependencies | Extra project dependencies | |
shared_data | Additional shared-data entries, which take precedence in case of conflicts | |
shared_scripts | Additional shared-scripts entries, which take precedence in case of conflicts | |
extra_metadata | Additional extra-metadata entries, which take precedence in case of conflicts | |
force_include_editable | Similar to the force_include option but specifically for the editable version and takes precedence |
Custom environment collector¶
This is a custom class in a given Python file that inherits from the EnvironmentCollectorInterface.
Configuration¶
The environment collector plugin name is custom.
[tool.hatch.env.collectors.custom]
+[env.collectors.custom]
+Options¶
| Option | Default | Description |
|---|---|---|
path | hatch_plugins.py | The path of the Python file |
Example¶
from hatch.env.collectors.plugin.interface import EnvironmentCollectorInterface
+
+
+ class CustomEnvironmentCollector(EnvironmentCollectorInterface):
+ ...
+If multiple subclasses are found, you must define a function named get_environment_collector that returns the desired environment collector.
Note
Any defined PLUGIN_NAME is ignored and will always be custom.
Environment collector plugins¶
Environment collectors allow for dynamically modifying environments or adding environments beyond those defined in config. Users can override default values provided by each environment.
Known third-party¶
- hatch-mkdocs - integrate MkDocs and infer dependencies into an env
Installation¶
Any required environment collectors that are not built-in must be manually installed alongside Hatch or listed in the tool.hatch.env.requires array for automatic management:
[tool.hatch.env]
+requires = [
+ "...",
+]
+[env]
+requires = [
+ "...",
+]
+ EnvironmentCollectorInterface ¶
Example usage:
from hatch.env.collectors.plugin.interface import EnvironmentCollectorInterface
+
+
+ class SpecialEnvironmentCollector(EnvironmentCollectorInterface):
+ PLUGIN_NAME = 'special'
+ ...
+ from hatchling.plugin import hookimpl
+
+ from .plugin import SpecialEnvironmentCollector
+
+
+ @hookimpl
+ def hatch_register_environment_collector():
+ return SpecialEnvironmentCollector
+Source code in src/hatch/env/collectors/plugin/interface.py
class EnvironmentCollectorInterface:
+ """
+ Example usage:
+
+ ```python tab="plugin.py"
+ from hatch.env.collectors.plugin.interface import EnvironmentCollectorInterface
+
+
+ class SpecialEnvironmentCollector(EnvironmentCollectorInterface):
+ PLUGIN_NAME = 'special'
+ ...
+ ```
+
+ ```python tab="hooks.py"
+ from hatchling.plugin import hookimpl
+
+ from .plugin import SpecialEnvironmentCollector
+
+
+ @hookimpl
+ def hatch_register_environment_collector():
+ return SpecialEnvironmentCollector
+ ```
+ """
+
+ PLUGIN_NAME = ''
+ """The name used for selection."""
+
+ def __init__(self, root, config):
+ self.__root = root
+ self.__config = config
+
+ @property
+ def root(self):
+ """
+ The root of the project tree as a path-like object.
+ """
+ return self.__root
+
+ @property
+ def config(self) -> dict:
+ """
+ ```toml config-example
+ [tool.hatch.env.collectors.<PLUGIN_NAME>]
+ ```
+ """
+ return self.__config
+
+ def get_initial_config(self) -> dict[str, dict]: # noqa: PLR6301
+ """
+ Returns configuration for environments keyed by the environment or matrix name.
+ """
+ return {}
+
+ def finalize_config(self, config: dict[str, dict]):
+ """
+ Finalizes configuration for environments keyed by the environment or matrix name. This will override
+ any user-defined settings and any collectors that ran before this call.
+
+ This is called before matrices are turned into concrete environments.
+ """
+
+ def finalize_environments(self, config: dict[str, dict]):
+ """
+ Finalizes configuration for environments keyed by the environment name. This will override
+ any user-defined settings and any collectors that ran before this call.
+
+ This is called after matrices are turned into concrete environments.
+ """
+ PLUGIN_NAME = '' class-attribute instance-attribute ¶
The name used for selection.
root property ¶
The root of the project tree as a path-like object.
config: dict property ¶
[tool.hatch.env.collectors.<PLUGIN_NAME>]
+[env.collectors.<PLUGIN_NAME>]
+ get_initial_config() -> dict[str, dict] ¶
Returns configuration for environments keyed by the environment or matrix name.
Source code in src/hatch/env/collectors/plugin/interface.py
def get_initial_config(self) -> dict[str, dict]: # noqa: PLR6301
+ """
+ Returns configuration for environments keyed by the environment or matrix name.
+ """
+ return {}
+ finalize_config(config: dict[str, dict]) ¶
Finalizes configuration for environments keyed by the environment or matrix name. This will override any user-defined settings and any collectors that ran before this call.
This is called before matrices are turned into concrete environments.
Source code in src/hatch/env/collectors/plugin/interface.py
def finalize_config(self, config: dict[str, dict]):
+ """
+ Finalizes configuration for environments keyed by the environment or matrix name. This will override
+ any user-defined settings and any collectors that ran before this call.
+
+ This is called before matrices are turned into concrete environments.
+ """
+ finalize_environments(config: dict[str, dict]) ¶
Finalizes configuration for environments keyed by the environment name. This will override any user-defined settings and any collectors that ran before this call.
This is called after matrices are turned into concrete environments.
Source code in src/hatch/env/collectors/plugin/interface.py
def finalize_environments(self, config: dict[str, dict]):
+ """
+ Finalizes configuration for environments keyed by the environment name. This will override
+ any user-defined settings and any collectors that ran before this call.
+
+ This is called after matrices are turned into concrete environments.
+ """
+Environment plugins¶
See the documentation for environment configuration.
Known third-party¶
- hatch-conda - environments backed by Conda/Mamba
- hatch-containers - environments run inside containers
- hatch-pip-compile - use pip-compile to manage project dependencies and lockfiles
- hatch-pip-deepfreeze - virtual environments with dependency locking by pip-deepfreeze
Installation¶
Any required environment types that are not built-in must be manually installed alongside Hatch or listed in the tool.hatch.env.requires array for automatic management:
[tool.hatch.env]
+requires = [
+ "...",
+]
+[env]
+requires = [
+ "...",
+]
+Life cycle¶
Whenever an environment is used, the following logic is performed:
Source code in src/hatch/cli/application.py
def prepare_environment(self, environment: EnvironmentInterface):
+ if not environment.exists():
+ self.env_metadata.reset(environment)
+
+ with environment.app_status_creation():
+ environment.create()
+
+ if not environment.skip_install:
+ if environment.pre_install_commands:
+ with environment.app_status_pre_installation():
+ self.run_shell_commands(
+ ExecutionContext(
+ environment,
+ shell_commands=environment.pre_install_commands,
+ source='pre-install',
+ show_code_on_error=True,
+ )
+ )
+
+ with environment.app_status_project_installation():
+ if environment.dev_mode:
+ environment.install_project_dev_mode()
+ else:
+ environment.install_project()
+
+ if environment.post_install_commands:
+ with environment.app_status_post_installation():
+ self.run_shell_commands(
+ ExecutionContext(
+ environment,
+ shell_commands=environment.post_install_commands,
+ source='post-install',
+ show_code_on_error=True,
+ )
+ )
+
+ with environment.app_status_dependency_state_check():
+ new_dep_hash = environment.dependency_hash()
+
+ current_dep_hash = self.env_metadata.dependency_hash(environment)
+ if new_dep_hash != current_dep_hash:
+ with environment.app_status_dependency_installation_check():
+ dependencies_in_sync = environment.dependencies_in_sync()
+
+ if not dependencies_in_sync:
+ with environment.app_status_dependency_synchronization():
+ environment.sync_dependencies()
+ new_dep_hash = environment.dependency_hash()
+
+ self.env_metadata.update_dependency_hash(environment, new_dep_hash)
+Build environments¶
All environment types should offer support for a special sub-environment in which projects can be built. This environment is used in the following scenarios:
- the
buildcommand - commands that read dependencies, like
dep hash, if any project dependencies are set dynamically
EnvironmentInterface ¶
Example usage:
from hatch.env.plugin.interface import EnvironmentInterface
+
+
+ class SpecialEnvironment(EnvironmentInterface):
+ PLUGIN_NAME = 'special'
+ ...
+ from hatchling.plugin import hookimpl
+
+ from .plugin import SpecialEnvironment
+
+
+ @hookimpl
+ def hatch_register_environment():
+ return SpecialEnvironment
+Source code in src/hatch/env/plugin/interface.py
class EnvironmentInterface(ABC):
+ """
+ Example usage:
+
+ ```python tab="plugin.py"
+ from hatch.env.plugin.interface import EnvironmentInterface
+
+
+ class SpecialEnvironment(EnvironmentInterface):
+ PLUGIN_NAME = 'special'
+ ...
+ ```
+
+ ```python tab="hooks.py"
+ from hatchling.plugin import hookimpl
+
+ from .plugin import SpecialEnvironment
+
+
+ @hookimpl
+ def hatch_register_environment():
+ return SpecialEnvironment
+ ```
+ """
+
+ PLUGIN_NAME = ''
+ """The name used for selection."""
+
+ def __init__(
+ self,
+ root,
+ metadata,
+ name,
+ config,
+ matrix_variables,
+ data_directory,
+ isolated_data_directory,
+ platform,
+ verbosity,
+ app=None,
+ ):
+ self.__root = root
+ self.__metadata = metadata
+ self.__name = name
+ self.__config = config
+ self.__matrix_variables = matrix_variables
+ self.__data_directory = data_directory
+ self.__isolated_data_directory = isolated_data_directory
+ self.__platform = platform
+ self.__verbosity = verbosity
+ self.__app = app
+ self.__context = None
+
+ self._system_python = None
+ self._env_vars = None
+ self._env_include = None
+ self._env_exclude = None
+ self._environment_dependencies_complex = None
+ self._environment_dependencies = None
+ self._dependencies_complex = None
+ self._dependencies = None
+ self._platforms = None
+ self._skip_install = None
+ self._dev_mode = None
+ self._features = None
+ self._description = None
+ self._scripts = None
+ self._pre_install_commands = None
+ self._post_install_commands = None
+
+ @property
+ def matrix_variables(self):
+ return self.__matrix_variables
+
+ @property
+ def app(self):
+ """
+ An instance of [Application](../utilities.md#hatchling.bridge.app.Application).
+ """
+ if self.__app is None:
+ from hatchling.bridge.app import Application
+
+ self.__app = Application().get_safe_application()
+
+ return self.__app
+
+ @property
+ def context(self):
+ if self.__context is None:
+ self.__context = self.get_context()
+
+ return self.__context
+
+ @property
+ def verbosity(self):
+ return self.__verbosity
+
+ @property
+ def root(self):
+ """
+ The root of the project tree as a path-like object.
+ """
+ return self.__root
+
+ @property
+ def metadata(self):
+ return self.__metadata
+
+ @property
+ def name(self) -> str:
+ """
+ The name of the environment.
+ """
+ return self.__name
+
+ @property
+ def platform(self):
+ """
+ An instance of [Platform](../utilities.md#hatch.utils.platform.Platform).
+ """
+ return self.__platform
+
+ @property
+ def data_directory(self):
+ """
+ The [directory](../../config/hatch.md#environments) this plugin should use for storage as a path-like object.
+ If the user has not configured one then this will be the same as the
+ [isolated data directory](reference.md#hatch.env.plugin.interface.EnvironmentInterface.isolated_data_directory).
+ """
+ return self.__data_directory
+
+ @property
+ def isolated_data_directory(self):
+ """
+ The default [directory](../../config/hatch.md#environments) reserved exclusively for this plugin as a path-like
+ object.
+ """
+ return self.__isolated_data_directory
+
+ @property
+ def config(self) -> dict:
+ """
+ ```toml config-example
+ [tool.hatch.envs.<ENV_NAME>]
+ ```
+ """
+ return self.__config
+
+ @property
+ def system_python(self):
+ if self._system_python is None:
+ system_python = os.environ.get(AppEnvVars.PYTHON)
+ if system_python == 'self':
+ system_python = sys.executable
+
+ system_python = (
+ system_python
+ or self.platform.modules.shutil.which('python')
+ or self.platform.modules.shutil.which('python3')
+ or sys.executable
+ )
+ if not isabs(system_python):
+ system_python = self.platform.modules.shutil.which(system_python)
+
+ self._system_python = system_python
+
+ return self._system_python
+
+ @property
+ def env_vars(self) -> dict:
+ """
+ ```toml config-example
+ [tool.hatch.envs.<ENV_NAME>.env-vars]
+ ```
+ """
+ if self._env_vars is None:
+ env_vars = self.config.get('env-vars', {})
+ if not isinstance(env_vars, dict):
+ message = f'Field `tool.hatch.envs.{self.name}.env-vars` must be a mapping'
+ raise TypeError(message)
+
+ for key, value in env_vars.items():
+ if not isinstance(value, str):
+ message = (
+ f'Environment variable `{key}` of field `tool.hatch.envs.{self.name}.env-vars` must be a string'
+ )
+ raise TypeError(message)
+
+ new_env_vars = {}
+ with self.metadata.context.apply_context(self.context):
+ for key, value in env_vars.items():
+ new_env_vars[key] = self.metadata.context.format(value)
+
+ new_env_vars[AppEnvVars.ENV_ACTIVE] = self.name
+ self._env_vars = new_env_vars
+
+ return self._env_vars
+
+ @property
+ def env_include(self) -> list[str]:
+ """
+ ```toml config-example
+ [tool.hatch.envs.<ENV_NAME>]
+ env-include = [...]
+ ```
+ """
+ if self._env_include is None:
+ env_include = self.config.get('env-include', [])
+ if not isinstance(env_include, list):
+ message = f'Field `tool.hatch.envs.{self.name}.env-include` must be an array'
+ raise TypeError(message)
+
+ for i, pattern in enumerate(env_include, 1):
+ if not isinstance(pattern, str):
+ message = f'Pattern #{i} of field `tool.hatch.envs.{self.name}.env-include` must be a string'
+ raise TypeError(message)
+
+ if env_include:
+ self._env_include = ['HATCH_BUILD_*', *env_include]
+ else:
+ self._env_include = env_include
+
+ return self._env_include
+
+ @property
+ def env_exclude(self) -> list[str]:
+ """
+ ```toml config-example
+ [tool.hatch.envs.<ENV_NAME>]
+ env-exclude = [...]
+ ```
+ """
+ if self._env_exclude is None:
+ env_exclude = self.config.get('env-exclude', [])
+ if not isinstance(env_exclude, list):
+ message = f'Field `tool.hatch.envs.{self.name}.env-exclude` must be an array'
+ raise TypeError(message)
+
+ for i, pattern in enumerate(env_exclude, 1):
+ if not isinstance(pattern, str):
+ message = f'Pattern #{i} of field `tool.hatch.envs.{self.name}.env-exclude` must be a string'
+ raise TypeError(message)
+
+ self._env_exclude = env_exclude
+
+ return self._env_exclude
+
+ @property
+ def environment_dependencies_complex(self):
+ if self._environment_dependencies_complex is None:
+ from packaging.requirements import InvalidRequirement, Requirement
+
+ dependencies_complex = []
+ with self.apply_context():
+ for option in ('dependencies', 'extra-dependencies'):
+ dependencies = self.config.get(option, [])
+ if not isinstance(dependencies, list):
+ message = f'Field `tool.hatch.envs.{self.name}.{option}` must be an array'
+ raise TypeError(message)
+
+ for i, entry in enumerate(dependencies, 1):
+ if not isinstance(entry, str):
+ message = (
+ f'Dependency #{i} of field `tool.hatch.envs.{self.name}.{option}` must be a string'
+ )
+ raise TypeError(message)
+
+ try:
+ dependencies_complex.append(Requirement(self.metadata.context.format(entry)))
+ except InvalidRequirement as e:
+ message = f'Dependency #{i} of field `tool.hatch.envs.{self.name}.{option}` is invalid: {e}'
+ raise ValueError(message) from None
+
+ self._environment_dependencies_complex = dependencies_complex
+
+ return self._environment_dependencies_complex
+
+ @property
+ def environment_dependencies(self) -> list[str]:
+ """
+ The list of all [environment dependencies](../../config/environment/overview.md#dependencies).
+ """
+ if self._environment_dependencies is None:
+ self._environment_dependencies = [str(dependency) for dependency in self.environment_dependencies_complex]
+
+ return self._environment_dependencies
+
+ @property
+ def dependencies_complex(self):
+ if self._dependencies_complex is None:
+ all_dependencies_complex = list(self.environment_dependencies_complex)
+
+ # Ensure these are checked last to speed up initial environment creation since
+ # they will already be installed along with the project
+ if (not self.skip_install and self.dev_mode) or self.features:
+ from hatch.utils.dep import get_project_dependencies_complex
+
+ dependencies_complex, optional_dependencies_complex = get_project_dependencies_complex(self)
+
+ if not self.skip_install and self.dev_mode:
+ all_dependencies_complex.extend(dependencies_complex.values())
+
+ for feature in self.features:
+ if feature not in optional_dependencies_complex:
+ message = (
+ f'Feature `{feature}` of field `tool.hatch.envs.{self.name}.features` is not '
+ f'defined in the dynamic field `project.optional-dependencies`'
+ )
+ raise ValueError(message)
+
+ all_dependencies_complex.extend(optional_dependencies_complex[feature].values())
+
+ self._dependencies_complex = all_dependencies_complex
+
+ return self._dependencies_complex
+
+ @property
+ def dependencies(self) -> list[str]:
+ """
+ The list of all [project dependencies](../../config/metadata.md#dependencies) (if
+ [installed](../../config/environment/overview.md#skip-install) and in
+ [dev mode](../../config/environment/overview.md#dev-mode)), selected
+ [optional dependencies](../../config/environment/overview.md#features), and
+ [environment dependencies](../../config/environment/overview.md#dependencies).
+ """
+ if self._dependencies is None:
+ self._dependencies = [str(dependency) for dependency in self.dependencies_complex]
+
+ return self._dependencies
+
+ @property
+ def platforms(self) -> list[str]:
+ """
+ All names are stored as their lower-cased version.
+
+ ```toml config-example
+ [tool.hatch.envs.<ENV_NAME>]
+ platforms = [...]
+ ```
+ """
+ if self._platforms is None:
+ platforms = self.config.get('platforms', [])
+ if not isinstance(platforms, list):
+ message = f'Field `tool.hatch.envs.{self.name}.platforms` must be an array'
+ raise TypeError(message)
+
+ for i, command in enumerate(platforms, 1):
+ if not isinstance(command, str):
+ message = f'Platform #{i} of field `tool.hatch.envs.{self.name}.platforms` must be a string'
+ raise TypeError(message)
+
+ self._platforms = [platform.lower() for platform in platforms]
+
+ return self._platforms
+
+ @property
+ def skip_install(self) -> bool:
+ """
+ ```toml config-example
+ [tool.hatch.envs.<ENV_NAME>]
+ skip-install = ...
+ ```
+ """
+ if self._skip_install is None:
+ skip_install = self.config.get('skip-install', not self.metadata.has_project_file())
+ if not isinstance(skip_install, bool):
+ message = f'Field `tool.hatch.envs.{self.name}.skip-install` must be a boolean'
+ raise TypeError(message)
+
+ self._skip_install = skip_install
+
+ return self._skip_install
+
+ @property
+ def dev_mode(self) -> bool:
+ """
+ ```toml config-example
+ [tool.hatch.envs.<ENV_NAME>]
+ dev-mode = ...
+ ```
+ """
+ if self._dev_mode is None:
+ dev_mode = self.config.get('dev-mode', True)
+ if not isinstance(dev_mode, bool):
+ message = f'Field `tool.hatch.envs.{self.name}.dev-mode` must be a boolean'
+ raise TypeError(message)
+
+ self._dev_mode = dev_mode
+
+ return self._dev_mode
+
+ @property
+ def features(self):
+ if self._features is None:
+ from hatchling.metadata.utils import normalize_project_name
+
+ features = self.config.get('features', [])
+ if not isinstance(features, list):
+ message = f'Field `tool.hatch.envs.{self.name}.features` must be an array of strings'
+ raise TypeError(message)
+
+ all_features = set()
+ for i, feature in enumerate(features, 1):
+ if not isinstance(feature, str):
+ message = f'Feature #{i} of field `tool.hatch.envs.{self.name}.features` must be a string'
+ raise TypeError(message)
+
+ if not feature:
+ message = f'Feature #{i} of field `tool.hatch.envs.{self.name}.features` cannot be an empty string'
+ raise ValueError(message)
+
+ normalized_feature = (
+ feature
+ if self.metadata.hatch.metadata.allow_ambiguous_features
+ else normalize_project_name(feature)
+ )
+ if (
+ not self.metadata.hatch.metadata.hook_config
+ and normalized_feature not in self.metadata.core.optional_dependencies
+ ):
+ message = (
+ f'Feature `{normalized_feature}` of field `tool.hatch.envs.{self.name}.features` is not '
+ f'defined in field `project.optional-dependencies`'
+ )
+ raise ValueError(message)
+
+ all_features.add(normalized_feature)
+
+ self._features = sorted(all_features)
+
+ return self._features
+
+ @property
+ def description(self) -> str:
+ """
+ ```toml config-example
+ [tool.hatch.envs.<ENV_NAME>]
+ description = ...
+ ```
+ """
+ if self._description is None:
+ description = self.config.get('description', '')
+ if not isinstance(description, str):
+ message = f'Field `tool.hatch.envs.{self.name}.description` must be a string'
+ raise TypeError(message)
+
+ self._description = description
+
+ return self._description
+
+ @property
+ def scripts(self):
+ if self._scripts is None:
+ config = {}
+
+ # Extra scripts should come first to give less precedence
+ for field in ('extra-scripts', 'scripts'):
+ script_config = self.config.get(field, {})
+ if not isinstance(script_config, dict):
+ message = f'Field `tool.hatch.envs.{self.name}.{field}` must be a table'
+ raise TypeError(message)
+
+ for name, data in script_config.items():
+ if ' ' in name:
+ message = (
+ f'Script name `{name}` in field `tool.hatch.envs.{self.name}.{field}` '
+ f'must not contain spaces'
+ )
+ raise ValueError(message)
+
+ commands = []
+
+ if isinstance(data, str):
+ commands.append(data)
+ elif isinstance(data, list):
+ for i, command in enumerate(data, 1):
+ if not isinstance(command, str):
+ message = (
+ f'Command #{i} in field `tool.hatch.envs.{self.name}.{field}.{name}` '
+ f'must be a string'
+ )
+ raise TypeError(message)
+
+ commands.append(command)
+ else:
+ message = (
+ f'Field `tool.hatch.envs.{self.name}.{field}.{name}` must be '
+ f'a string or an array of strings'
+ )
+ raise TypeError(message)
+
+ config[name] = commands
+
+ seen = {}
+ active = []
+ for script_name, commands in config.items():
+ commands[:] = expand_script_commands(self.name, script_name, commands, config, seen, active)
+
+ self._scripts = config
+
+ return self._scripts
+
+ @property
+ def pre_install_commands(self):
+ if self._pre_install_commands is None:
+ pre_install_commands = self.config.get('pre-install-commands', [])
+ if not isinstance(pre_install_commands, list):
+ message = f'Field `tool.hatch.envs.{self.name}.pre-install-commands` must be an array'
+ raise TypeError(message)
+
+ for i, command in enumerate(pre_install_commands, 1):
+ if not isinstance(command, str):
+ message = (
+ f'Command #{i} of field `tool.hatch.envs.{self.name}.pre-install-commands` must be a string'
+ )
+ raise TypeError(message)
+
+ self._pre_install_commands = list(pre_install_commands)
+
+ return self._pre_install_commands
+
+ @property
+ def post_install_commands(self):
+ if self._post_install_commands is None:
+ post_install_commands = self.config.get('post-install-commands', [])
+ if not isinstance(post_install_commands, list):
+ message = f'Field `tool.hatch.envs.{self.name}.post-install-commands` must be an array'
+ raise TypeError(message)
+
+ for i, command in enumerate(post_install_commands, 1):
+ if not isinstance(command, str):
+ message = (
+ f'Command #{i} of field `tool.hatch.envs.{self.name}.post-install-commands` must be a string'
+ )
+ raise TypeError(message)
+
+ self._post_install_commands = list(post_install_commands)
+
+ return self._post_install_commands
+
+ def activate(self):
+ """
+ A convenience method called when using the environment as a context manager:
+
+ ```python
+ with environment:
+ ...
+ ```
+ """
+
+ def deactivate(self):
+ """
+ A convenience method called after using the environment as a context manager:
+
+ ```python
+ with environment:
+ ...
+ ```
+ """
+
+ @abstractmethod
+ def find(self):
+ """
+ :material-align-horizontal-left: **REQUIRED** :material-align-horizontal-right:
+
+ This should return information about how to locate the environment or represent its ID in
+ some way. Additionally, this is expected to return something even if the environment is
+ [incompatible](reference.md#hatch.env.plugin.interface.EnvironmentInterface.check_compatibility).
+ """
+
+ @abstractmethod
+ def create(self):
+ """
+ :material-align-horizontal-left: **REQUIRED** :material-align-horizontal-right:
+
+ This should perform the necessary steps to set up the environment.
+ """
+
+ @abstractmethod
+ def remove(self):
+ """
+ :material-align-horizontal-left: **REQUIRED** :material-align-horizontal-right:
+
+ This should perform the necessary steps to completely remove the environment from the system and will only
+ be triggered manually by users with the [`env remove`](../../cli/reference.md#hatch-env-remove) or
+ [`env prune`](../../cli/reference.md#hatch-env-prune) commands.
+
+ If the
+ [build environment](reference.md#hatch.env.plugin.interface.EnvironmentInterface.build_environment)
+ has a caching mechanism, this should remove that as well.
+ """
+
+ @abstractmethod
+ def exists(self) -> bool:
+ """
+ :material-align-horizontal-left: **REQUIRED** :material-align-horizontal-right:
+
+ This should indicate whether or not the environment has already been created.
+ """
+
+ @abstractmethod
+ def install_project(self):
+ """
+ :material-align-horizontal-left: **REQUIRED** :material-align-horizontal-right:
+
+ This should install the project in the environment.
+ """
+
+ @abstractmethod
+ def install_project_dev_mode(self):
+ """
+ :material-align-horizontal-left: **REQUIRED** :material-align-horizontal-right:
+
+ This should install the project in the environment such that the environment
+ always reflects the current state of the project.
+ """
+
+ @abstractmethod
+ def dependencies_in_sync(self) -> bool:
+ """
+ :material-align-horizontal-left: **REQUIRED** :material-align-horizontal-right:
+
+ This should indicate whether or not the environment is compatible with the current
+ [dependencies](reference.md#hatch.env.plugin.interface.EnvironmentInterface.dependencies).
+ """
+
+ @abstractmethod
+ def sync_dependencies(self):
+ """
+ :material-align-horizontal-left: **REQUIRED** :material-align-horizontal-right:
+
+ This should install the
+ [dependencies](reference.md#hatch.env.plugin.interface.EnvironmentInterface.dependencies)
+ in the environment.
+ """
+
+ def dependency_hash(self):
+ """
+ This should return a hash of the environment's
+ [dependencies](reference.md#hatch.env.plugin.interface.EnvironmentInterface.dependencies)
+ and any other data that is handled by the
+ [sync_dependencies](reference.md#hatch.env.plugin.interface.EnvironmentInterface.sync_dependencies)
+ and
+ [dependencies_in_sync](reference.md#hatch.env.plugin.interface.EnvironmentInterface.dependencies_in_sync)
+ methods.
+ """
+ from hatch.utils.dep import hash_dependencies
+
+ return hash_dependencies(self.dependencies_complex)
+
+ @contextmanager
+ def app_status_creation(self):
+ """
+ See the [life cycle of environments](reference.md#life-cycle).
+ """
+ with self.app.status(f'Creating environment: {self.name}'):
+ yield
+
+ @contextmanager
+ def app_status_pre_installation(self):
+ """
+ See the [life cycle of environments](reference.md#life-cycle).
+ """
+ with self.app.status('Running pre-installation commands'):
+ yield
+
+ @contextmanager
+ def app_status_post_installation(self):
+ """
+ See the [life cycle of environments](reference.md#life-cycle).
+ """
+ with self.app.status('Running post-installation commands'):
+ yield
+
+ @contextmanager
+ def app_status_project_installation(self):
+ """
+ See the [life cycle of environments](reference.md#life-cycle).
+ """
+ if self.dev_mode:
+ with self.app.status('Installing project in development mode'):
+ yield
+ else:
+ with self.app.status('Installing project'):
+ yield
+
+ @contextmanager
+ def app_status_dependency_state_check(self):
+ """
+ See the [life cycle of environments](reference.md#life-cycle).
+ """
+ if not self.skip_install and (
+ 'dependencies' in self.metadata.dynamic or 'optional-dependencies' in self.metadata.dynamic
+ ):
+ with self.app.status('Polling dependency state'):
+ yield
+ else:
+ yield
+
+ @contextmanager
+ def app_status_dependency_installation_check(self):
+ """
+ See the [life cycle of environments](reference.md#life-cycle).
+ """
+ with self.app.status('Checking dependencies'):
+ yield
+
+ @contextmanager
+ def app_status_dependency_synchronization(self):
+ """
+ See the [life cycle of environments](reference.md#life-cycle).
+ """
+ with self.app.status('Syncing dependencies'):
+ yield
+
+ @contextmanager
+ def build_environment(
+ self,
+ dependencies: list[str], # noqa: ARG002
+ ):
+ """
+ This should set up an isolated environment in which to [`build`](../../cli/reference.md#hatch-build) the project
+ given a set of dependencies and must be a context manager:
+
+ ```python
+ with environment.build_environment([...]):
+ ...
+ ```
+
+ The build environment should reflect any
+ [environment variables](reference.md#hatch.env.plugin.interface.EnvironmentInterface.get_env_vars)
+ the user defined either currently or at the time of
+ [creation](reference.md#hatch.env.plugin.interface.EnvironmentInterface.create).
+ """
+ with self.get_env_vars():
+ yield
+
+ def run_builder(
+ self,
+ build_environment, # noqa: ARG002
+ **kwargs,
+ ):
+ """
+ This will be called when the
+ [build environment](reference.md#hatch.env.plugin.interface.EnvironmentInterface.build_environment)
+ is active:
+
+ ```python
+ with environment.build_environment([...]) as build_env:
+ process = environment.run_builder(build_env, ...)
+ ```
+
+ This should return the standard library's
+ [subprocess.CompletedProcess](https://docs.python.org/3/library/subprocess.html#subprocess.CompletedProcess).
+ The command is constructed by passing all keyword arguments to
+ [construct_build_command](reference.md#hatch.env.plugin.interface.EnvironmentInterface.construct_build_command).
+
+ For an example, open the default implementation below:
+ """
+ return self.platform.run_command(self.construct_build_command(**kwargs))
+
+ def build_environment_exists(self): # noqa: PLR6301
+ """
+ If the
+ [build environment](reference.md#hatch.env.plugin.interface.EnvironmentInterface.build_environment)
+ has a caching mechanism, this should indicate whether or not it has already been created.
+ """
+ return False
+
+ def enter_shell(
+ self,
+ name: str, # noqa: ARG002
+ path: str,
+ args: Iterable[str],
+ ):
+ """
+ Spawn a [shell](../../config/hatch.md#shell) within the environment.
+
+ This should either use
+ [command_context](reference.md#hatch.env.plugin.interface.EnvironmentInterface.command_context)
+ directly or provide the same guarantee.
+ """
+ with self.command_context():
+ self.platform.exit_with_command([path, *args])
+
+ def run_shell_command(self, command: str, **kwargs):
+ """
+ This should return the standard library's
+ [subprocess.CompletedProcess](https://docs.python.org/3/library/subprocess.html#subprocess.CompletedProcess)
+ and will always be called when the
+ [command_context](reference.md#hatch.env.plugin.interface.EnvironmentInterface.command_context)
+ is active, with the expectation of providing the same guarantee.
+ """
+ kwargs.setdefault('shell', True)
+ return self.platform.run_command(command, **kwargs)
+
+ @contextmanager
+ def command_context(self):
+ """
+ A context manager that when active should make executed shell commands reflect any
+ [environment variables](reference.md#hatch.env.plugin.interface.EnvironmentInterface.get_env_vars)
+ the user defined either currently or at the time of
+ [creation](reference.md#hatch.env.plugin.interface.EnvironmentInterface.create).
+
+ For an example, open the default implementation below:
+ """
+ with self.get_env_vars():
+ yield
+
+ def resolve_commands(self, commands: list[str]):
+ """
+ This expands each command into one or more commands based on any
+ [scripts](../../config/environment/overview.md#scripts) that the user defined.
+ """
+ for command in commands:
+ yield from self.expand_command(command)
+
+ def expand_command(self, command):
+ possible_script, args, _ignore_exit_code = parse_script_command(command)
+
+ # Indicate undefined
+ if not args:
+ args = None
+
+ with self.apply_context():
+ if possible_script in self.scripts:
+ if args is not None:
+ args = self.metadata.context.format(args)
+
+ for cmd in self.scripts[possible_script]:
+ yield self.metadata.context.format(cmd, args=args).strip()
+ else:
+ yield self.metadata.context.format(command, args=args).strip()
+
+ def construct_build_command( # noqa: PLR6301
+ self,
+ *,
+ directory=None,
+ targets=(),
+ hooks_only=False,
+ no_hooks=False,
+ clean=False,
+ clean_hooks_after=False,
+ clean_only=False,
+ ):
+ """
+ This is the canonical way [`build`](../../cli/reference.md#hatch-build) command options are translated to
+ a subprocess command issued to [builders](../builder/reference.md).
+ """
+ command = ['python', '-u', '-m', 'hatchling', 'build']
+
+ if directory:
+ command.extend(('--directory', directory))
+
+ if targets:
+ for target in targets:
+ command.extend(('--target', target))
+
+ if hooks_only:
+ command.append('--hooks-only')
+
+ if no_hooks:
+ command.append('--no-hooks')
+
+ if clean:
+ command.append('--clean')
+
+ if clean_hooks_after:
+ command.append('--clean-hooks-after')
+
+ if clean_only:
+ command.append('--clean-only')
+
+ return command
+
+ def construct_pip_install_command(self, args: list[str]):
+ """
+ A convenience method for constructing a [`pip install`](https://pip.pypa.io/en/stable/cli/pip_install/)
+ command with the given verbosity. The default verbosity is set to one less than Hatch's verbosity.
+ """
+ command = ['python', '-u', '-m', 'pip', 'install', '--disable-pip-version-check', '--no-python-version-warning']
+
+ # Default to -1 verbosity
+ add_verbosity_flag(command, self.verbosity, adjustment=-1)
+
+ command.extend(args)
+ return command
+
+ def join_command_args(self, args: list[str]):
+ """
+ This is used by the [`run`](../../cli/reference.md#hatch-run) command to construct the root command string
+ from the received arguments.
+ """
+ return self.platform.join_command_args(args)
+
+ def apply_features(self, requirement: str):
+ """
+ A convenience method that applies any user defined [features](../../config/environment/overview.md#features)
+ to the given requirement.
+ """
+ if self.features:
+ features = ','.join(self.features)
+ return f'{requirement}[{features}]'
+
+ return requirement
+
+ def check_compatibility(self):
+ """
+ This raises an exception if the environment is not compatible with the user's setup. The default behavior
+ checks for [platform compatibility](../../config/environment/overview.md#supported-platforms)
+ and any method override should keep this check.
+
+ This check is never performed if the environment has been
+ [created](reference.md#hatch.env.plugin.interface.EnvironmentInterface.create).
+ """
+ if self.platforms and self.platform.name not in self.platforms:
+ message = 'unsupported platform'
+ raise OSError(message)
+
+ def get_env_vars(self) -> EnvVars:
+ """
+ Returns a mapping of environment variables that should be available to the environment. The object can
+ be used as a context manager to temporarily apply the environment variables to the current process.
+
+ !!! note
+ The environment variable `HATCH_ENV_ACTIVE` will always be set to the name of the environment.
+ """
+ return EnvVars(self.env_vars, self.env_include, self.env_exclude)
+
+ def get_env_var_option(self, option: str) -> str:
+ """
+ Returns the value of the upper-cased environment variable `HATCH_ENV_TYPE_<PLUGIN_NAME>_<option>`.
+ """
+ return get_env_var_option(plugin_name=self.PLUGIN_NAME, option=option)
+
+ def get_context(self):
+ """
+ Returns a subclass of
+ [EnvironmentContextFormatter](../utilities.md#hatch.env.context.EnvironmentContextFormatter).
+ """
+ from hatch.env.context import EnvironmentContextFormatter
+
+ return EnvironmentContextFormatter(self)
+
+ @staticmethod
+ def get_option_types() -> dict:
+ """
+ Returns a mapping of supported options to their respective types so that they can be used by
+ [overrides](../../config/environment/advanced.md#option-overrides).
+ """
+ return {}
+
+ @contextmanager
+ def apply_context(self):
+ with self.get_env_vars(), self.metadata.context.apply_context(self.context):
+ yield
+
+ def __enter__(self):
+ self.activate()
+ return self
+
+ def __exit__(self, exc_type, exc_value, traceback):
+ self.deactivate()
+ PLUGIN_NAME = '' class-attribute instance-attribute ¶
The name used for selection.
app property ¶
An instance of Application.
root property ¶
The root of the project tree as a path-like object.
name: str property ¶
The name of the environment.
data_directory property ¶
The directory this plugin should use for storage as a path-like object. If the user has not configured one then this will be the same as the isolated data directory.
isolated_data_directory property ¶
The default directory reserved exclusively for this plugin as a path-like object.
config: dict property ¶
[tool.hatch.envs.<ENV_NAME>]
+[envs.<ENV_NAME>]
+ environment_dependencies: list[str] property ¶
The list of all environment dependencies.
dependencies: list[str] property ¶
The list of all project dependencies (if installed and in dev mode), selected optional dependencies, and environment dependencies.
env_vars: dict property ¶
[tool.hatch.envs.<ENV_NAME>.env-vars]
+[envs.<ENV_NAME>.env-vars]
+ env_include: list[str] property ¶
[tool.hatch.envs.<ENV_NAME>]
+env-include = [...]
+[envs.<ENV_NAME>]
+env-include = [...]
+ env_exclude: list[str] property ¶
[tool.hatch.envs.<ENV_NAME>]
+env-exclude = [...]
+[envs.<ENV_NAME>]
+env-exclude = [...]
+ platforms: list[str] property ¶
All names are stored as their lower-cased version.
[tool.hatch.envs.<ENV_NAME>]
+platforms = [...]
+[envs.<ENV_NAME>]
+platforms = [...]
+ skip_install: bool property ¶
[tool.hatch.envs.<ENV_NAME>]
+skip-install = ...
+[envs.<ENV_NAME>]
+skip-install = ...
+ dev_mode: bool property ¶
[tool.hatch.envs.<ENV_NAME>]
+dev-mode = ...
+[envs.<ENV_NAME>]
+dev-mode = ...
+ description: str property ¶
[tool.hatch.envs.<ENV_NAME>]
+description = ...
+[envs.<ENV_NAME>]
+description = ...
+ find() abstractmethod ¶
REQUIRED
This should return information about how to locate the environment or represent its ID in some way. Additionally, this is expected to return something even if the environment is incompatible.
Source code in src/hatch/env/plugin/interface.py
@abstractmethod
+def find(self):
+ """
+ :material-align-horizontal-left: **REQUIRED** :material-align-horizontal-right:
+
+ This should return information about how to locate the environment or represent its ID in
+ some way. Additionally, this is expected to return something even if the environment is
+ [incompatible](reference.md#hatch.env.plugin.interface.EnvironmentInterface.check_compatibility).
+ """
+ create() abstractmethod ¶
REQUIRED
This should perform the necessary steps to set up the environment.
Source code in src/hatch/env/plugin/interface.py
@abstractmethod
+def create(self):
+ """
+ :material-align-horizontal-left: **REQUIRED** :material-align-horizontal-right:
+
+ This should perform the necessary steps to set up the environment.
+ """
+ remove() abstractmethod ¶
REQUIRED
This should perform the necessary steps to completely remove the environment from the system and will only be triggered manually by users with the env remove or env prune commands.
If the build environment has a caching mechanism, this should remove that as well.
Source code in src/hatch/env/plugin/interface.py
@abstractmethod
+def remove(self):
+ """
+ :material-align-horizontal-left: **REQUIRED** :material-align-horizontal-right:
+
+ This should perform the necessary steps to completely remove the environment from the system and will only
+ be triggered manually by users with the [`env remove`](../../cli/reference.md#hatch-env-remove) or
+ [`env prune`](../../cli/reference.md#hatch-env-prune) commands.
+
+ If the
+ [build environment](reference.md#hatch.env.plugin.interface.EnvironmentInterface.build_environment)
+ has a caching mechanism, this should remove that as well.
+ """
+ exists() -> bool abstractmethod ¶
REQUIRED
This should indicate whether or not the environment has already been created.
Source code in src/hatch/env/plugin/interface.py
@abstractmethod
+def exists(self) -> bool:
+ """
+ :material-align-horizontal-left: **REQUIRED** :material-align-horizontal-right:
+
+ This should indicate whether or not the environment has already been created.
+ """
+ install_project() abstractmethod ¶
REQUIRED
This should install the project in the environment.
Source code in src/hatch/env/plugin/interface.py
@abstractmethod
+def install_project(self):
+ """
+ :material-align-horizontal-left: **REQUIRED** :material-align-horizontal-right:
+
+ This should install the project in the environment.
+ """
+ install_project_dev_mode() abstractmethod ¶
REQUIRED
This should install the project in the environment such that the environment always reflects the current state of the project.
Source code in src/hatch/env/plugin/interface.py
@abstractmethod
+def install_project_dev_mode(self):
+ """
+ :material-align-horizontal-left: **REQUIRED** :material-align-horizontal-right:
+
+ This should install the project in the environment such that the environment
+ always reflects the current state of the project.
+ """
+ dependencies_in_sync() -> bool abstractmethod ¶
REQUIRED
This should indicate whether or not the environment is compatible with the current dependencies.
Source code in src/hatch/env/plugin/interface.py
@abstractmethod
+def dependencies_in_sync(self) -> bool:
+ """
+ :material-align-horizontal-left: **REQUIRED** :material-align-horizontal-right:
+
+ This should indicate whether or not the environment is compatible with the current
+ [dependencies](reference.md#hatch.env.plugin.interface.EnvironmentInterface.dependencies).
+ """
+ sync_dependencies() abstractmethod ¶
REQUIRED
This should install the dependencies in the environment.
Source code in src/hatch/env/plugin/interface.py
@abstractmethod
+def sync_dependencies(self):
+ """
+ :material-align-horizontal-left: **REQUIRED** :material-align-horizontal-right:
+
+ This should install the
+ [dependencies](reference.md#hatch.env.plugin.interface.EnvironmentInterface.dependencies)
+ in the environment.
+ """
+ dependency_hash() ¶
This should return a hash of the environment's dependencies and any other data that is handled by the sync_dependencies and dependencies_in_sync methods.
Source code in src/hatch/env/plugin/interface.py
def dependency_hash(self):
+ """
+ This should return a hash of the environment's
+ [dependencies](reference.md#hatch.env.plugin.interface.EnvironmentInterface.dependencies)
+ and any other data that is handled by the
+ [sync_dependencies](reference.md#hatch.env.plugin.interface.EnvironmentInterface.sync_dependencies)
+ and
+ [dependencies_in_sync](reference.md#hatch.env.plugin.interface.EnvironmentInterface.dependencies_in_sync)
+ methods.
+ """
+ from hatch.utils.dep import hash_dependencies
+
+ return hash_dependencies(self.dependencies_complex)
+ build_environment(dependencies: list[str]) ¶
This should set up an isolated environment in which to build the project given a set of dependencies and must be a context manager:
with environment.build_environment([...]):
+ ...
+The build environment should reflect any environment variables the user defined either currently or at the time of creation.
Source code in src/hatch/env/plugin/interface.py
@contextmanager
+def build_environment(
+ self,
+ dependencies: list[str], # noqa: ARG002
+):
+ """
+ This should set up an isolated environment in which to [`build`](../../cli/reference.md#hatch-build) the project
+ given a set of dependencies and must be a context manager:
+
+ ```python
+ with environment.build_environment([...]):
+ ...
+ ```
+
+ The build environment should reflect any
+ [environment variables](reference.md#hatch.env.plugin.interface.EnvironmentInterface.get_env_vars)
+ the user defined either currently or at the time of
+ [creation](reference.md#hatch.env.plugin.interface.EnvironmentInterface.create).
+ """
+ with self.get_env_vars():
+ yield
+ build_environment_exists() ¶
If the build environment has a caching mechanism, this should indicate whether or not it has already been created.
Source code in src/hatch/env/plugin/interface.py
def build_environment_exists(self): # noqa: PLR6301
+ """
+ If the
+ [build environment](reference.md#hatch.env.plugin.interface.EnvironmentInterface.build_environment)
+ has a caching mechanism, this should indicate whether or not it has already been created.
+ """
+ return False
+ activate() ¶
A convenience method called when using the environment as a context manager:
with environment:
+ ...
+Source code in src/hatch/env/plugin/interface.py
def activate(self):
+ """
+ A convenience method called when using the environment as a context manager:
+
+ ```python
+ with environment:
+ ...
+ ```
+ """
+ deactivate() ¶
A convenience method called after using the environment as a context manager:
with environment:
+ ...
+Source code in src/hatch/env/plugin/interface.py
def deactivate(self):
+ """
+ A convenience method called after using the environment as a context manager:
+
+ ```python
+ with environment:
+ ...
+ ```
+ """
+ app_status_creation() ¶
See the life cycle of environments.
Source code in src/hatch/env/plugin/interface.py
@contextmanager
+def app_status_creation(self):
+ """
+ See the [life cycle of environments](reference.md#life-cycle).
+ """
+ with self.app.status(f'Creating environment: {self.name}'):
+ yield
+ app_status_pre_installation() ¶
See the life cycle of environments.
Source code in src/hatch/env/plugin/interface.py
@contextmanager
+def app_status_pre_installation(self):
+ """
+ See the [life cycle of environments](reference.md#life-cycle).
+ """
+ with self.app.status('Running pre-installation commands'):
+ yield
+ app_status_post_installation() ¶
See the life cycle of environments.
Source code in src/hatch/env/plugin/interface.py
@contextmanager
+def app_status_post_installation(self):
+ """
+ See the [life cycle of environments](reference.md#life-cycle).
+ """
+ with self.app.status('Running post-installation commands'):
+ yield
+ app_status_project_installation() ¶
See the life cycle of environments.
Source code in src/hatch/env/plugin/interface.py
@contextmanager
+def app_status_project_installation(self):
+ """
+ See the [life cycle of environments](reference.md#life-cycle).
+ """
+ if self.dev_mode:
+ with self.app.status('Installing project in development mode'):
+ yield
+ else:
+ with self.app.status('Installing project'):
+ yield
+ app_status_dependency_state_check() ¶
See the life cycle of environments.
Source code in src/hatch/env/plugin/interface.py
@contextmanager
+def app_status_dependency_state_check(self):
+ """
+ See the [life cycle of environments](reference.md#life-cycle).
+ """
+ if not self.skip_install and (
+ 'dependencies' in self.metadata.dynamic or 'optional-dependencies' in self.metadata.dynamic
+ ):
+ with self.app.status('Polling dependency state'):
+ yield
+ else:
+ yield
+ app_status_dependency_installation_check() ¶
See the life cycle of environments.
Source code in src/hatch/env/plugin/interface.py
@contextmanager
+def app_status_dependency_installation_check(self):
+ """
+ See the [life cycle of environments](reference.md#life-cycle).
+ """
+ with self.app.status('Checking dependencies'):
+ yield
+ app_status_dependency_synchronization() ¶
See the life cycle of environments.
Source code in src/hatch/env/plugin/interface.py
@contextmanager
+def app_status_dependency_synchronization(self):
+ """
+ See the [life cycle of environments](reference.md#life-cycle).
+ """
+ with self.app.status('Syncing dependencies'):
+ yield
+ run_builder(build_environment, **kwargs) ¶
This will be called when the build environment is active:
with environment.build_environment([...]) as build_env:
+ process = environment.run_builder(build_env, ...)
+This should return the standard library's subprocess.CompletedProcess. The command is constructed by passing all keyword arguments to construct_build_command.
For an example, open the default implementation below:
Source code in src/hatch/env/plugin/interface.py
def run_builder(
+ self,
+ build_environment, # noqa: ARG002
+ **kwargs,
+):
+ """
+ This will be called when the
+ [build environment](reference.md#hatch.env.plugin.interface.EnvironmentInterface.build_environment)
+ is active:
+
+ ```python
+ with environment.build_environment([...]) as build_env:
+ process = environment.run_builder(build_env, ...)
+ ```
+
+ This should return the standard library's
+ [subprocess.CompletedProcess](https://docs.python.org/3/library/subprocess.html#subprocess.CompletedProcess).
+ The command is constructed by passing all keyword arguments to
+ [construct_build_command](reference.md#hatch.env.plugin.interface.EnvironmentInterface.construct_build_command).
+
+ For an example, open the default implementation below:
+ """
+ return self.platform.run_command(self.construct_build_command(**kwargs))
+ construct_build_command(*, directory=None, targets=(), hooks_only=False, no_hooks=False, clean=False, clean_hooks_after=False, clean_only=False) ¶
This is the canonical way build command options are translated to a subprocess command issued to builders.
Source code in src/hatch/env/plugin/interface.py
def construct_build_command( # noqa: PLR6301
+ self,
+ *,
+ directory=None,
+ targets=(),
+ hooks_only=False,
+ no_hooks=False,
+ clean=False,
+ clean_hooks_after=False,
+ clean_only=False,
+):
+ """
+ This is the canonical way [`build`](../../cli/reference.md#hatch-build) command options are translated to
+ a subprocess command issued to [builders](../builder/reference.md).
+ """
+ command = ['python', '-u', '-m', 'hatchling', 'build']
+
+ if directory:
+ command.extend(('--directory', directory))
+
+ if targets:
+ for target in targets:
+ command.extend(('--target', target))
+
+ if hooks_only:
+ command.append('--hooks-only')
+
+ if no_hooks:
+ command.append('--no-hooks')
+
+ if clean:
+ command.append('--clean')
+
+ if clean_hooks_after:
+ command.append('--clean-hooks-after')
+
+ if clean_only:
+ command.append('--clean-only')
+
+ return command
+ command_context() ¶
A context manager that when active should make executed shell commands reflect any environment variables the user defined either currently or at the time of creation.
For an example, open the default implementation below:
Source code in src/hatch/env/plugin/interface.py
@contextmanager
+def command_context(self):
+ """
+ A context manager that when active should make executed shell commands reflect any
+ [environment variables](reference.md#hatch.env.plugin.interface.EnvironmentInterface.get_env_vars)
+ the user defined either currently or at the time of
+ [creation](reference.md#hatch.env.plugin.interface.EnvironmentInterface.create).
+
+ For an example, open the default implementation below:
+ """
+ with self.get_env_vars():
+ yield
+ enter_shell(name: str, path: str, args: Iterable[str]) ¶
Spawn a shell within the environment.
This should either use command_context directly or provide the same guarantee.
Source code in src/hatch/env/plugin/interface.py
def enter_shell(
+ self,
+ name: str, # noqa: ARG002
+ path: str,
+ args: Iterable[str],
+):
+ """
+ Spawn a [shell](../../config/hatch.md#shell) within the environment.
+
+ This should either use
+ [command_context](reference.md#hatch.env.plugin.interface.EnvironmentInterface.command_context)
+ directly or provide the same guarantee.
+ """
+ with self.command_context():
+ self.platform.exit_with_command([path, *args])
+ run_shell_command(command: str, **kwargs) ¶
This should return the standard library's subprocess.CompletedProcess and will always be called when the command_context is active, with the expectation of providing the same guarantee.
Source code in src/hatch/env/plugin/interface.py
def run_shell_command(self, command: str, **kwargs):
+ """
+ This should return the standard library's
+ [subprocess.CompletedProcess](https://docs.python.org/3/library/subprocess.html#subprocess.CompletedProcess)
+ and will always be called when the
+ [command_context](reference.md#hatch.env.plugin.interface.EnvironmentInterface.command_context)
+ is active, with the expectation of providing the same guarantee.
+ """
+ kwargs.setdefault('shell', True)
+ return self.platform.run_command(command, **kwargs)
+ resolve_commands(commands: list[str]) ¶
This expands each command into one or more commands based on any scripts that the user defined.
Source code in src/hatch/env/plugin/interface.py
def resolve_commands(self, commands: list[str]):
+ """
+ This expands each command into one or more commands based on any
+ [scripts](../../config/environment/overview.md#scripts) that the user defined.
+ """
+ for command in commands:
+ yield from self.expand_command(command)
+ get_env_vars() -> EnvVars ¶
Returns a mapping of environment variables that should be available to the environment. The object can be used as a context manager to temporarily apply the environment variables to the current process.
Note
The environment variable HATCH_ENV_ACTIVE will always be set to the name of the environment.
Source code in src/hatch/env/plugin/interface.py
def get_env_vars(self) -> EnvVars:
+ """
+ Returns a mapping of environment variables that should be available to the environment. The object can
+ be used as a context manager to temporarily apply the environment variables to the current process.
+
+ !!! note
+ The environment variable `HATCH_ENV_ACTIVE` will always be set to the name of the environment.
+ """
+ return EnvVars(self.env_vars, self.env_include, self.env_exclude)
+ apply_features(requirement: str) ¶
A convenience method that applies any user defined features to the given requirement.
Source code in src/hatch/env/plugin/interface.py
def apply_features(self, requirement: str):
+ """
+ A convenience method that applies any user defined [features](../../config/environment/overview.md#features)
+ to the given requirement.
+ """
+ if self.features:
+ features = ','.join(self.features)
+ return f'{requirement}[{features}]'
+
+ return requirement
+ construct_pip_install_command(args: list[str]) ¶
A convenience method for constructing a pip install command with the given verbosity. The default verbosity is set to one less than Hatch's verbosity.
Source code in src/hatch/env/plugin/interface.py
def construct_pip_install_command(self, args: list[str]):
+ """
+ A convenience method for constructing a [`pip install`](https://pip.pypa.io/en/stable/cli/pip_install/)
+ command with the given verbosity. The default verbosity is set to one less than Hatch's verbosity.
+ """
+ command = ['python', '-u', '-m', 'pip', 'install', '--disable-pip-version-check', '--no-python-version-warning']
+
+ # Default to -1 verbosity
+ add_verbosity_flag(command, self.verbosity, adjustment=-1)
+
+ command.extend(args)
+ return command
+ join_command_args(args: list[str]) ¶
This is used by the run command to construct the root command string from the received arguments.
Source code in src/hatch/env/plugin/interface.py
def join_command_args(self, args: list[str]):
+ """
+ This is used by the [`run`](../../cli/reference.md#hatch-run) command to construct the root command string
+ from the received arguments.
+ """
+ return self.platform.join_command_args(args)
+ check_compatibility() ¶
This raises an exception if the environment is not compatible with the user's setup. The default behavior checks for platform compatibility and any method override should keep this check.
This check is never performed if the environment has been created.
Source code in src/hatch/env/plugin/interface.py
def check_compatibility(self):
+ """
+ This raises an exception if the environment is not compatible with the user's setup. The default behavior
+ checks for [platform compatibility](../../config/environment/overview.md#supported-platforms)
+ and any method override should keep this check.
+
+ This check is never performed if the environment has been
+ [created](reference.md#hatch.env.plugin.interface.EnvironmentInterface.create).
+ """
+ if self.platforms and self.platform.name not in self.platforms:
+ message = 'unsupported platform'
+ raise OSError(message)
+ get_option_types() -> dict staticmethod ¶
Returns a mapping of supported options to their respective types so that they can be used by overrides.
Source code in src/hatch/env/plugin/interface.py
@staticmethod
+def get_option_types() -> dict:
+ """
+ Returns a mapping of supported options to their respective types so that they can be used by
+ [overrides](../../config/environment/advanced.md#option-overrides).
+ """
+ return {}
+ get_env_var_option(option: str) -> str ¶
Returns the value of the upper-cased environment variable HATCH_ENV_TYPE_<PLUGIN_NAME>_<option>.
Source code in src/hatch/env/plugin/interface.py
def get_env_var_option(self, option: str) -> str:
+ """
+ Returns the value of the upper-cased environment variable `HATCH_ENV_TYPE_<PLUGIN_NAME>_<option>`.
+ """
+ return get_env_var_option(plugin_name=self.PLUGIN_NAME, option=option)
+ get_context() ¶
Returns a subclass of EnvironmentContextFormatter.
Source code in src/hatch/env/plugin/interface.py
def get_context(self):
+ """
+ Returns a subclass of
+ [EnvironmentContextFormatter](../utilities.md#hatch.env.context.EnvironmentContextFormatter).
+ """
+ from hatch.env.context import EnvironmentContextFormatter
+
+ return EnvironmentContextFormatter(self)
+Virtual environment¶
This uses virtual environments backed by virtualenv or UV.
Configuration¶
The environment plugin name is virtual.
[tool.hatch.envs.<ENV_NAME>]
+type = "virtual"
+[envs.<ENV_NAME>]
+type = "virtual"
+Options¶
| Option | Default | Description |
|---|---|---|
python | The version of Python to find on your system and subsequently use to create the environment, defaulting to the HATCH_PYTHON environment variable, followed by the normal resolution logic. Setting the HATCH_PYTHON environment variable to self will force the use of the Python executable Hatch is running on. For more information, see the documentation. | |
python-sources | ['external', 'internal'] | This may be set to an array of strings that are either the literal internal or external. External considers only Python executables that are already on PATH. Internal considers only internally managed Python distributions. |
path | An explicit path to the virtual environment. The path may be absolute or relative to the project root. Any environments that inherit this option will also use this path. The environment variable HATCH_ENV_TYPE_VIRTUAL_PATH may be used, which will take precedence. | |
system-packages | false | Whether or not to give the virtual environment access to the system site-packages directory |
installer | pip | When set to uv, UV will be used in place of virtualenv & pip for virtual environment creation and dependency management, respectively. If you intend to provide UV yourself, you may set the HATCH_ENV_TYPE_VIRTUAL_UV_PATH environment variable which should be the absolute path to a UV binary. This environment variable implicitly sets the installer option to uv (if unset). |
Location¶
The location of environments is determined in the following heuristic order:
- The
pathoption - A directory named after the environment within the configured
virtualenvironment directory if the directory resides somewhere within the project root or if it is set to a.virtualenvsdirectory within the user's home directory - Otherwise, environments are stored within the configured
virtualenvironment directory in a deeply nested structure in order to support multiple projects
Additionally, when the path option is not used, the name of the directory for the default environment will be the normalized project name to provide a more meaningful default shell prompt.
Python resolution¶
Virtual environments necessarily require a parent installation of Python. The following rules determine how the parent is resolved.
The Python choice is determined by the python option followed by the HATCH_PYTHON environment variable. If the choice is via the environment variable, then resolution stops and that path is used unconditionally.
The resolvers will be based on the python-sources option and all resolved interpreters will ensure compatibility with the project's defined Python support.
If a Python version has been chosen then each resolver will try to find an interpreter that satisfies that version.
If no version has been chosen, then each resolver will try to find a version that matches the version of Python that Hatch is currently running on. If not found then each resolver will try to find the highest compatible version.
Note
Some external Python paths are considered unstable and are ignored during resolution. For example, if Hatch is installed via Homebrew then sys.executable will be ignored because the interpreter could change or be removed at any time.
Note
When resolution finds a match using an internally managed distribution and an update is available, the latest distribution will automatically be downloaded before environment creation.
Internal distributions¶
The following options are recognized for internal Python resolution.
Tip
You can set custom sources for distributions by setting the HATCH_PYTHON_SOURCE_<NAME> environment variable where <NAME> is the uppercased version of the distribution name with periods replaced by underscores e.g. HATCH_PYTHON_SOURCE_PYPY3_10.
CPython¶
| NAME |
|---|
3.7 |
3.8 |
3.9 |
3.10 |
3.11 |
3.12 |
3.13 |
The source of distributions is the python-build-standalone project.
Some distributions have variants that may be configured. Options may be combined.
| Option | Platforms | Allowed values |
|---|---|---|
HATCH_PYTHON_VARIANT_CPU |
|
|
HATCH_PYTHON_VARIANT_GIL |
|
|
PyPy¶
| NAME |
|---|
pypy2.7 |
pypy3.9 |
pypy3.10 |
The source of distributions is the PyPy project.
Troubleshooting¶
macOS SIP¶
If you need to set linker environment variables like those starting with DYLD_ or LD_, any executable secured by System Integrity Protection that is invoked when running commands will not see those environment variable modifications as macOS strips those.
Hatch interprets such commands as shell commands but deliberately ignores such paths to protected shells. This workaround suffices for the majority of use cases but there are 2 situations in which it may not:
- There are no unprotected
sh,bash,zsh, norfishexecutables found along PATH. - The desired executable is a project's script, and the location of environments contains spaces or is longer than 1241 characters. In this case
pipand other installers will create such an entry point with a shebang pointing to/bin/sh(which is protected) to avoid shebang limitations. Rather than changing the location, you could invoke the script as e.g.python -m pytest(if the project supports that method of invocation by shipping a__main__.py).
Custom metadata hook¶
This is a custom class in a given Python file that inherits from the MetadataHookInterface.
Configuration¶
The metadata hook plugin name is custom.
[tool.hatch.metadata.hooks.custom]
+[metadata.hooks.custom]
+Options¶
| Option | Default | Description |
|---|---|---|
path | hatch_build.py | The path of the Python file |
Example¶
from hatchling.metadata.plugin.interface import MetadataHookInterface
+
+
+class CustomMetadataHook(MetadataHookInterface):
+ ...
+If multiple subclasses are found, you must define a function named get_metadata_hook that returns the desired build hook.
Note
Any defined PLUGIN_NAME is ignored and will always be custom.
Metadata hook plugins¶
Metadata hooks allow for the modification of project metadata after it has been loaded.
Known third-party¶
- hatch-docstring-description - set the project description using docstrings
- hatch-fancy-pypi-readme - dynamically construct the README
- hatch-nodejs-version - uses fields from NodeJS
package.jsonfiles - hatch-odoo - determine dependencies based on manifests of Odoo add-ons
- hatch-requirements-txt - read project dependencies from
requirements.txtfiles - UniDep - for unified
pipandcondadependency management using a singlerequirements.yamlfile for both
MetadataHookInterface ¶
Example usage:
from hatchling.metadata.plugin.interface import MetadataHookInterface
+
+
+class SpecialMetadataHook(MetadataHookInterface):
+ PLUGIN_NAME = 'special'
+ ...
+from hatchling.plugin import hookimpl
+
+from .plugin import SpecialMetadataHook
+
+
+@hookimpl
+def hatch_register_metadata_hook():
+ return SpecialMetadataHook
+Source code in backend/src/hatchling/metadata/plugin/interface.py
class MetadataHookInterface(ABC): # no cov
+ """
+ Example usage:
+
+ ```python tab="plugin.py"
+ from hatchling.metadata.plugin.interface import MetadataHookInterface
+
+
+ class SpecialMetadataHook(MetadataHookInterface):
+ PLUGIN_NAME = 'special'
+ ...
+ ```
+
+ ```python tab="hooks.py"
+ from hatchling.plugin import hookimpl
+
+ from .plugin import SpecialMetadataHook
+
+
+ @hookimpl
+ def hatch_register_metadata_hook():
+ return SpecialMetadataHook
+ ```
+ """
+
+ PLUGIN_NAME = ''
+ """The name used for selection."""
+
+ def __init__(self, root: str, config: dict) -> None:
+ self.__root = root
+ self.__config = config
+
+ @property
+ def root(self) -> str:
+ """
+ The root of the project tree.
+ """
+ return self.__root
+
+ @property
+ def config(self) -> dict:
+ """
+ The hook configuration.
+
+ ```toml config-example
+ [tool.hatch.metadata.hooks.<PLUGIN_NAME>]
+ ```
+ """
+ return self.__config
+
+ @abstractmethod
+ def update(self, metadata: dict) -> None:
+ """
+ This updates the metadata mapping of the `project` table in-place.
+ """
+
+ def get_known_classifiers(self) -> list[str]: # noqa: PLR6301
+ """
+ This returns extra classifiers that should be considered valid in addition to the ones known to PyPI.
+ """
+ return []
+ PLUGIN_NAME = '' class-attribute instance-attribute ¶
The name used for selection.
root: str property ¶
The root of the project tree.
config: dict property ¶
The hook configuration.
[tool.hatch.metadata.hooks.<PLUGIN_NAME>]
+[metadata.hooks.<PLUGIN_NAME>]
+ update(metadata: dict) -> None abstractmethod ¶
This updates the metadata mapping of the project table in-place.
Source code in backend/src/hatchling/metadata/plugin/interface.py
@abstractmethod
+def update(self, metadata: dict) -> None:
+ """
+ This updates the metadata mapping of the `project` table in-place.
+ """
+ get_known_classifiers() -> list[str] ¶
This returns extra classifiers that should be considered valid in addition to the ones known to PyPI.
Source code in backend/src/hatchling/metadata/plugin/interface.py
def get_known_classifiers(self) -> list[str]: # noqa: PLR6301
+ """
+ This returns extra classifiers that should be considered valid in addition to the ones known to PyPI.
+ """
+ return []
+Index publisher¶
See the documentation for publishing.
Options¶
| Flag | Config name | Description |
|---|---|---|
-r/--repo | repo | The repository with which to publish artifacts |
-u/--user | user | The user with which to authenticate |
-a/--auth | auth | The credentials to use for authentication |
--ca-cert | ca-cert | The path to a CA bundle |
--client-cert | client-cert | The path to a client certificate, optionally containing the private key |
--client-key | client-key | The path to the client certificate's private key |
repos | A table of named repositories to their respective options |
Configuration¶
The publisher plugin name is index.
[publish.index]
+Repositories¶
All top-level options can be overridden per repository using the repos table with a required url attribute for each repository. The following shows the default configuration:
[publish.index.repos.main]
+url = "https://upload.pypi.org/legacy/"
+
+[publish.index.repos.test]
+url = "https://test.pypi.org/legacy/"
+The repo and repos options have no effect.
Confirmation prompt¶
You can require a confirmation prompt or use of the -y/--yes flag by setting publishers' disable option to true in either Hatch's config file or project-specific configuration (which takes precedence):
[publish.index]
+disable = true
+[tool.hatch.publish.index]
+disable = true
+[publish.index]
+disable = true
+Publisher plugins¶
Known third-party¶
- hatch-aws-publisher - publish AWS Lambda functions with SAM
PublisherInterface ¶
Example usage:
from hatch.publish.plugin.interface import PublisherInterface
+
+
+ class SpecialPublisher(PublisherInterface):
+ PLUGIN_NAME = 'special'
+ ...
+ from hatchling.plugin import hookimpl
+
+ from .plugin import SpecialPublisher
+
+
+ @hookimpl
+ def hatch_register_publisher():
+ return SpecialPublisher
+Source code in src/hatch/publish/plugin/interface.py
class PublisherInterface(ABC):
+ """
+ Example usage:
+
+ ```python tab="plugin.py"
+ from hatch.publish.plugin.interface import PublisherInterface
+
+
+ class SpecialPublisher(PublisherInterface):
+ PLUGIN_NAME = 'special'
+ ...
+ ```
+
+ ```python tab="hooks.py"
+ from hatchling.plugin import hookimpl
+
+ from .plugin import SpecialPublisher
+
+
+ @hookimpl
+ def hatch_register_publisher():
+ return SpecialPublisher
+ ```
+ """
+
+ PLUGIN_NAME = ''
+ """The name used for selection."""
+
+ def __init__(self, app, root, cache_dir, project_config, plugin_config):
+ self.__app = app
+ self.__root = root
+ self.__cache_dir = cache_dir
+ self.__project_config = project_config
+ self.__plugin_config = plugin_config
+
+ self.__disable = None
+
+ @property
+ def app(self):
+ """
+ An instance of [Application](../utilities.md#hatchling.bridge.app.Application).
+ """
+ return self.__app
+
+ @property
+ def root(self):
+ """
+ The root of the project tree as a path-like object.
+ """
+ return self.__root
+
+ @property
+ def cache_dir(self):
+ """
+ The directory reserved exclusively for this plugin as a path-like object.
+ """
+ return self.__cache_dir
+
+ @property
+ def project_config(self) -> dict:
+ """
+ ```toml config-example
+ [tool.hatch.publish.<PLUGIN_NAME>]
+ ```
+ """
+ return self.__project_config
+
+ @property
+ def plugin_config(self) -> dict:
+ """
+ This is defined in Hatch's [config file](../../config/hatch.md).
+
+ ```toml tab="config.toml"
+ [publish.<PLUGIN_NAME>]
+ ```
+ """
+ return self.__plugin_config
+
+ @property
+ def disable(self):
+ """
+ Whether this plugin is disabled, thus requiring confirmation when publishing. Local
+ [project configuration](reference.md#hatch.publish.plugin.interface.PublisherInterface.project_config)
+ takes precedence over global
+ [plugin configuration](reference.md#hatch.publish.plugin.interface.PublisherInterface.plugin_config).
+ """
+ if self.__disable is None:
+ if 'disable' in self.project_config:
+ disable = self.project_config['disable']
+ if not isinstance(disable, bool):
+ message = f'Field `tool.hatch.publish.{self.PLUGIN_NAME}.disable` must be a boolean'
+ raise TypeError(message)
+ else:
+ disable = self.plugin_config.get('disable', False)
+ if not isinstance(disable, bool):
+ message = f'Global plugin configuration `publish.{self.PLUGIN_NAME}.disable` must be a boolean'
+ raise TypeError(message)
+
+ self.__disable = disable
+
+ return self.__disable
+
+ @abstractmethod
+ def publish(self, artifacts: list[str], options: dict):
+ """
+ :material-align-horizontal-left: **REQUIRED** :material-align-horizontal-right:
+
+ This is called directly by the [`publish`](../../cli/reference.md#hatch-publish) command
+ with the arguments and options it receives.
+ """
+ PLUGIN_NAME = '' class-attribute instance-attribute ¶
The name used for selection.
app property ¶
An instance of Application.
root property ¶
The root of the project tree as a path-like object.
cache_dir property ¶
The directory reserved exclusively for this plugin as a path-like object.
project_config: dict property ¶
[tool.hatch.publish.<PLUGIN_NAME>]
+[publish.<PLUGIN_NAME>]
+ plugin_config: dict property ¶
This is defined in Hatch's config file.
[publish.<PLUGIN_NAME>]
+ disable property ¶
Whether this plugin is disabled, thus requiring confirmation when publishing. Local project configuration takes precedence over global plugin configuration.
publish(artifacts: list[str], options: dict) abstractmethod ¶
REQUIRED
This is called directly by the publish command with the arguments and options it receives.
Source code in src/hatch/publish/plugin/interface.py
@abstractmethod
+def publish(self, artifacts: list[str], options: dict):
+ """
+ :material-align-horizontal-left: **REQUIRED** :material-align-horizontal-right:
+
+ This is called directly by the [`publish`](../../cli/reference.md#hatch-publish) command
+ with the arguments and options it receives.
+ """
+Plugin utilities¶
hatchling.builders.utils.get_reproducible_timestamp() -> int ¶
Returns an int derived from the SOURCE_DATE_EPOCH environment variable; see https://reproducible-builds.org/specs/source-date-epoch/.
The default value will always be: 1580601600
Source code in backend/src/hatchling/builders/utils.py
def get_reproducible_timestamp() -> int:
+ """
+ Returns an `int` derived from the `SOURCE_DATE_EPOCH` environment variable; see
+ https://reproducible-builds.org/specs/source-date-epoch/.
+
+ The default value will always be: `1580601600`
+ """
+ return int(os.environ.get('SOURCE_DATE_EPOCH', '1580601600'))
+ BuilderConfig ¶
directory: str property ¶
ignore_vcs: bool property ¶
reproducible: bool property ¶
Whether or not the target should be built in a reproducible manner, defaulting to true.
dev_mode_dirs: list[str] property ¶
Directories which must be added to Python's search path in dev mode.
versions: list[str] property ¶
dependencies: list[str] property ¶
default_include() -> list ¶
default_exclude() -> list ¶
default_packages() -> list ¶
default_only_include() -> list ¶
Application ¶
The way output is displayed can be configured by users.
Important
Never import this directly; Hatch judiciously decides if a type of plugin requires the capabilities herein and will grant access via an attribute.
verbosity: int property ¶
The verbosity level of the application, with 0 as the default.
abort(message: str = '', code: int = 1, **kwargs: Any) -> None ¶
Terminate the program with the given return code.
display_debug(message: str = '', level: int = 1, **kwargs: Any) -> None ¶
Meant to be used for messages that are not useful for most user experiences. The level option must be between 1 and 3 (inclusive).
display_error(message: str = '', **kwargs: Any) -> None ¶
Meant to be used for messages indicating some unrecoverable error.
display_info(message: str = '', **kwargs: Any) -> None ¶
Meant to be used for messages conveying basic information.
display_success(message: str = '', **kwargs: Any) -> None ¶
Meant to be used for messages indicating some positive outcome.
display_waiting(message: str = '', **kwargs: Any) -> None ¶
Meant to be used for messages shown before potentially time consuming operations.
display_warning(message: str = '', **kwargs: Any) -> None ¶
Meant to be used for messages conveying important information.
Platform ¶
default_shell: str property ¶
Returns the default shell of the system.
On Windows systems first try the SHELL environment variable, if present, followed by the COMSPEC environment variable, defaulting to cmd. On all other platforms only the SHELL environment variable will be used, defaulting to bash.
modules: LazilyLoadedModules property ¶
Accessor for lazily loading modules that either take multiple milliseconds to import (like shutil and subprocess) or are not used on all platforms (like shlex).
home: Path property ¶
The user's home directory as a path-like object.
name: str property ¶
One of the following:
linuxwindowsmacos
display_name: str property ¶
One of the following:
LinuxWindowsmacOS
windows: bool property ¶
Indicates whether Hatch is running on Windows.
macos: bool property ¶
Indicates whether Hatch is running on macOS.
linux: bool property ¶
Indicates whether Hatch is running on neither Windows nor macOS.
format_for_subprocess(command: str | list[str], *, shell: bool) -> str | list[str] ¶
Format the given command in a cross-platform manner for immediate consumption by subprocess utilities.
run_command(command: str | list[str], *, shell: bool = False, **kwargs: Any) -> CompletedProcess ¶
Equivalent to the standard library's subprocess.run, with the command first being properly formatted.
check_command(command: str | list[str], *, shell: bool = False, **kwargs: Any) -> CompletedProcess ¶
Equivalent to run_command, but non-zero exit codes will gracefully end program execution.
check_command_output(command: str | list[str], *, shell: bool = False, **kwargs: Any) -> str ¶
Equivalent to the output from the process returned by capture_process, but non-zero exit codes will gracefully end program execution.
capture_process(command: str | list[str], *, shell: bool = False, **kwargs: Any) -> Popen ¶
Equivalent to the standard library's subprocess.Popen, with all output captured by stdout and the command first being properly formatted.
Version scheme plugins¶
Known third-party¶
- hatch-semver - uses semantic versioning
VersionSchemeInterface ¶
Example usage:
from hatchling.version.scheme.plugin.interface import VersionSchemeInterface
+
+
+class SpecialVersionScheme(VersionSchemeInterface):
+ PLUGIN_NAME = 'special'
+ ...
+from hatchling.plugin import hookimpl
+
+from .plugin import SpecialVersionScheme
+
+
+@hookimpl
+def hatch_register_version_scheme():
+ return SpecialVersionScheme
+Source code in backend/src/hatchling/version/scheme/plugin/interface.py
class VersionSchemeInterface(ABC): # no cov
+ """
+ Example usage:
+
+ ```python tab="plugin.py"
+ from hatchling.version.scheme.plugin.interface import VersionSchemeInterface
+
+
+ class SpecialVersionScheme(VersionSchemeInterface):
+ PLUGIN_NAME = 'special'
+ ...
+ ```
+
+ ```python tab="hooks.py"
+ from hatchling.plugin import hookimpl
+
+ from .plugin import SpecialVersionScheme
+
+
+ @hookimpl
+ def hatch_register_version_scheme():
+ return SpecialVersionScheme
+ ```
+ """
+
+ PLUGIN_NAME = ''
+ """The name used for selection."""
+
+ def __init__(self, root: str, config: dict) -> None:
+ self.__root = root
+ self.__config = config
+
+ @property
+ def root(self) -> str:
+ """
+ The root of the project tree as a string.
+ """
+ return self.__root
+
+ @property
+ def config(self) -> dict:
+ """
+ ```toml config-example
+ [tool.hatch.version]
+ ```
+ """
+ return self.__config
+
+ @abstractmethod
+ def update(self, desired_version: str, original_version: str, version_data: dict) -> str:
+ """
+ This should return a normalized form of the desired version and verify that it
+ is higher than the original version.
+ """
+ PLUGIN_NAME = '' class-attribute instance-attribute ¶
The name used for selection.
root: str property ¶
The root of the project tree as a string.
config: dict property ¶
[tool.hatch.version]
+[version]
+ update(desired_version: str, original_version: str, version_data: dict) -> str abstractmethod ¶
This should return a normalized form of the desired version and verify that it is higher than the original version.
Source code in backend/src/hatchling/version/scheme/plugin/interface.py
@abstractmethod
+def update(self, desired_version: str, original_version: str, version_data: dict) -> str:
+ """
+ This should return a normalized form of the desired version and verify that it
+ is higher than the original version.
+ """
+Standard version scheme¶
See the documentation for versioning.
Configuration¶
The version scheme plugin name is standard.
[tool.hatch.version]
+scheme = "standard"
+[version]
+scheme = "standard"
+Options¶
| Option | Description |
|---|---|
validate-bump | When setting a specific version, this determines whether to check that the new version is higher than the original. The default is true. |
Code version source¶
Updates¶
Setting the version is not supported.
Configuration¶
The version source plugin name is code.
[tool.hatch.version]
+source = "code"
+[version]
+source = "code"
+Options¶
| Option | Description |
|---|---|
path (required) | A relative path to a Python file or extension module that will be loaded |
expression | A Python expression that when evaluated in the context of the loaded file returns the version. The default expression is simply __version__. |
search-paths | A list of relative paths to directories that will be prepended to Python's search path |
Missing imports¶
If the chosen path imports another module in your project, then you'll need to use absolute imports coupled with the search-paths option. For example, say you need to load the following file:
from ._version import get_version
+
+ __version__ = get_version()
+You should change it to:
from pkg._version import get_version
+
+ __version__ = get_version()
+and the configuration would become:
[tool.hatch.version]
+source = "code"
+path = "src/pkg/__init__.py"
+search-paths = ["src"]
+[version]
+source = "code"
+path = "src/pkg/__init__.py"
+search-paths = ["src"]
+Environment version source¶
Retrieves the version from an environment variable. This can be useful in build pipelines where the version is set by an external trigger.
Updates¶
Setting the version is not supported.
Configuration¶
The version source plugin name is env.
[tool.hatch.version]
+source = "env"
+[version]
+source = "env"
+Options¶
| Option | Description |
|---|---|
variable (required) | The name of the environment variable |
Version source plugins¶
Known third-party¶
- hatch-vcs - uses your preferred version control system (like Git)
- hatch-nodejs-version - uses the
versionfield of NodeJSpackage.jsonfiles - hatch-regex-commit - automatically creates a Git commit and tag after version bumping
- versioningit - determines version from Git or Mercurial tags, with customizable version formatting
VersionSourceInterface ¶
Example usage:
from hatchling.version.source.plugin.interface import VersionSourceInterface
+
+
+class SpecialVersionSource(VersionSourceInterface):
+ PLUGIN_NAME = 'special'
+ ...
+from hatchling.plugin import hookimpl
+
+from .plugin import SpecialVersionSource
+
+
+@hookimpl
+def hatch_register_version_source():
+ return SpecialVersionSource
+Source code in backend/src/hatchling/version/source/plugin/interface.py
class VersionSourceInterface(ABC): # no cov
+ """
+ Example usage:
+
+ ```python tab="plugin.py"
+ from hatchling.version.source.plugin.interface import VersionSourceInterface
+
+
+ class SpecialVersionSource(VersionSourceInterface):
+ PLUGIN_NAME = 'special'
+ ...
+ ```
+
+ ```python tab="hooks.py"
+ from hatchling.plugin import hookimpl
+
+ from .plugin import SpecialVersionSource
+
+
+ @hookimpl
+ def hatch_register_version_source():
+ return SpecialVersionSource
+ ```
+ """
+
+ PLUGIN_NAME = ''
+ """The name used for selection."""
+
+ def __init__(self, root: str, config: dict) -> None:
+ self.__root = root
+ self.__config = config
+
+ @property
+ def root(self) -> str:
+ """
+ The root of the project tree as a string.
+ """
+ return self.__root
+
+ @property
+ def config(self) -> dict:
+ """
+ ```toml config-example
+ [tool.hatch.version]
+ ```
+ """
+ return self.__config
+
+ @abstractmethod
+ def get_version_data(self) -> dict:
+ """
+ This should return a mapping with a `version` key representing the current version of the project and will be
+ displayed when invoking the [`version`](../../cli/reference.md#hatch-version) command without any arguments.
+
+ The mapping can contain anything else and will be passed to
+ [set_version](reference.md#hatchling.version.source.plugin.interface.VersionSourceInterface.set_version)
+ when updating the version.
+ """
+
+ def set_version(self, version: str, version_data: dict) -> None:
+ """
+ This should update the version to the first argument with the data provided during retrieval.
+ """
+ raise NotImplementedError
+ PLUGIN_NAME = '' class-attribute instance-attribute ¶
The name used for selection.
root: str property ¶
The root of the project tree as a string.
config: dict property ¶
[tool.hatch.version]
+[version]
+ get_version_data() -> dict abstractmethod ¶
This should return a mapping with a version key representing the current version of the project and will be displayed when invoking the version command without any arguments.
The mapping can contain anything else and will be passed to set_version when updating the version.
Source code in backend/src/hatchling/version/source/plugin/interface.py
@abstractmethod
+def get_version_data(self) -> dict:
+ """
+ This should return a mapping with a `version` key representing the current version of the project and will be
+ displayed when invoking the [`version`](../../cli/reference.md#hatch-version) command without any arguments.
+
+ The mapping can contain anything else and will be passed to
+ [set_version](reference.md#hatchling.version.source.plugin.interface.VersionSourceInterface.set_version)
+ when updating the version.
+ """
+ set_version(version: str, version_data: dict) -> None ¶
This should update the version to the first argument with the data provided during retrieval.
Source code in backend/src/hatchling/version/source/plugin/interface.py
def set_version(self, version: str, version_data: dict) -> None:
+ """
+ This should update the version to the first argument with the data provided during retrieval.
+ """
+ raise NotImplementedError
+Regex version source¶
See the documentation for versioning.
Updates¶
Setting the version is supported.
Configuration¶
The version source plugin name is regex.
[tool.hatch.version]
+source = "regex"
+[version]
+source = "regex"
+Options¶
| Option | Description |
|---|---|
path (required) | A relative path to a file containing the project's version |
pattern | A regular expression that has a named group called version that represents the version. The default pattern looks for a variable named __version__ or VERSION that is set to a string containing the version, optionally prefixed with the lowercase letter v. |
Publishing¶
After your project is built, you can distribute it using the publish command.
The -p/--publisher option controls which publisher to use, with the default being index.
Artifact selection¶
By default, the dist directory located at the root of your project will be used:
$ hatch publish
+dist/hatch_demo-1rc0-py3-none-any.whl ... success
+dist/hatch_demo-1rc0.tar.gz ... success
+
+[hatch-demo]
+https://pypi.org/project/hatch-demo/1rc0/
+You can instead pass specific paths as arguments:
hatch publish /path/to/artifacts foo-1.tar.gz
+Only files ending with .whl or .tar.gz will be published.
Further resources¶
Please refer to the publisher plugin reference for configuration options.
There's a How-To on authentication and on options to select the target repository.
The publish command is implemented as a built-in plugin, if you're planning your own plugin, read about the publisher plugin API.
Hatch is a modern, extensible Python project manager. See the Why Hatch? page for more information.
-
Build system
Reproducible builds by default with a rich ecosystem of plugins
Configure builds
-
Environments
Robust environment management with support for custom scripts and UV
Getting started
-
Python management
Choose between easy manual installations or automatic as part of environments
Try it
-
Testing
Test execution with known best practices
Run
-
Static analysis
Static analysis backed by Ruff with up-to-date, sane defaults
Learn
-
Script runner
Execute Python scripts with specific dependencies and Python versions
Execute
-
Publishing
Easily upload to PyPI or other indices
See how
-
Versioning
Streamlined workflow for bumping versions
Managing versions
-
Project generation
Create new projects from templates with known best practices
Project setup
-
Responsive CLI
Hatch is up to 3x faster than equivalent tools
CLI reference
Hatch is distributed under the terms of the MIT license.
"},{"location":"#navigation","title":"Navigation","text":"Documentation for specific MAJOR.MINOR versions can be chosen by using the dropdown on the top of every page. The dev version reflects changes that have not yet been released.
Also, desktop readers can use special keyboard shortcuts:
Keys Action- , (comma)
- p
- . (period)
- n
- /
- s
Builds are configured using the tool.hatch.build table. Every target is defined by a section within tool.hatch.build.targets, for example:
[tool.hatch.build.targets.sdist]\nexclude = [\n \"/.github\",\n \"/docs\",\n]\n\n[tool.hatch.build.targets.wheel]\npackages = [\"src/foo\"]\n[build.targets.sdist]\nexclude = [\n \"/.github\",\n \"/docs\",\n]\n\n[build.targets.wheel]\npackages = [\"src/foo\"]\nInvoking the build command without any arguments will build the sdist and wheel targets:
$ hatch build\n[sdist]\ndist/hatch_demo-1rc0.tar.gz\n\n[wheel]\ndist/hatch_demo-1rc0-py3-none-any.whl\nTo only build specific targets, use the -t/--target option:
$ hatch build -t wheel\n[wheel]\ndist/hatch_demo-1rc0-py3-none-any.whl\nIf the target supports multiple versions, you can specify the exact versions to build by appending a colon followed by the desired versions separated by commas:
$ hatch -v build -t wheel:standard\n[wheel]\nBuilding `wheel` version `standard`\ndist/hatch_demo-1rc0-py3-none-any.whl\nHatch complies with modern Python packaging specs and therefore your projects can be used by other tools with Hatch serving as just the build backend.
So you could use tox as an alternative to Hatch's environment management, or cibuildwheel to distribute packages for every platform, and they both will transparently use Hatch without any extra modification.
"},{"location":"environment/","title":"Environments","text":"Environments are designed to allow for isolated workspaces for testing, building documentation, or anything else projects need.
Unless an environment is chosen explicitly, Hatch will use the default environment.
Tip
For a more comprehensive walk-through, see the Basic usage tutorial.
"},{"location":"environment/#creation","title":"Creation","text":"You can create environments by using the env create command. Let's enter the directory of the project we created in the setup phase:
$ hatch env create\nCreating environment: default\nInstalling project in development mode\nSyncing dependencies\nTip
You never need to manually create environments as spawning a shell or running commands within one will automatically trigger creation.
"},{"location":"environment/#entering-environments","title":"Entering environments","text":"You can spawn a shell within an environment by using the shell command.
$ hatch shell\n(hatch-demo) $\nNow confirm the project has been installed:
(hatch-demo) $ pip show hatch-demo\nName: hatch-demo\nVersion: 0.0.1\n...\nFinally, see where your environment's Python is located:
(hatch-demo) $ python -c \"import sys;print(sys.executable)\"\n...\nYou can type exit to leave the environment.
The run command allows you to execute commands in an environment as if you had already entered it. For example, running the following command will output the same path as before:
hatch run python -c \"import sys;print(sys.executable)\"\nTip
Be sure to check out how to define scripts for your project.
"},{"location":"environment/#dependencies","title":"Dependencies","text":"Hatch ensures that environments are always compatible with the currently defined project dependencies (if installed and in dev mode) and environment dependencies.
To add cowsay as a dependency, open pyproject.toml and add it to the dependencies array:
[project]\n...\ndependencies = [\n \"cowsay\"\n]\nThis dependency will be installed the next time you spawn a shell or run a command. For example:
$ hatch run cowsay -t \"Hello, world!\"\nSyncing dependencies\n _____________\n| Hello, world! |\n =============\n \\\n \\\n ^__^\n (oo)\\_______\n (__)\\ )\\/\\\n ||----w |\n || ||\nNote
The Syncing dependencies status will display temporarily when Hatch updates environments in response to any dependency changes that you make.
You can select which environment to enter or run commands in by using the -e/--env root option or by setting the HATCH_ENV environment variable.
The run command allows for more explicit selection by prepending <ENV_NAME>: to commands. For example, if you had the following configuration:
[tool.hatch.envs.docs]\ndependencies = [\n \"mkdocs\"\n]\n[tool.hatch.envs.docs.scripts]\nbuild = \"mkdocs build --clean --strict\"\nserve = \"mkdocs serve --dev-addr localhost:8000\"\n[envs.docs]\ndependencies = [\n \"mkdocs\"\n]\n[envs.docs.scripts]\nbuild = \"mkdocs build --clean --strict\"\nserve = \"mkdocs serve --dev-addr localhost:8000\"\nyou could then serve your documentation by running:
hatch run docs:serve\nTip
If you've already entered an environment, commands will target it by default.
"},{"location":"environment/#matrix","title":"Matrix","text":"Every environment can define its own set of matrices:
pyproject.toml hatch.toml[tool.hatch.envs.test]\ndependencies = [\n \"pytest\"\n]\n\n[[tool.hatch.envs.test.matrix]]\npython = [\"3.10\", \"3.11\"]\nversion = [\"42\", \"3.14\"]\n\n[[tool.hatch.envs.test.matrix]]\npython = [\"3.11\", \"3.12\"]\nversion = [\"9000\"]\nfeature = [\"foo\", \"bar\"]\n[envs.test]\ndependencies = [\n \"pytest\"\n]\n\n[[envs.test.matrix]]\npython = [\"3.10\", \"3.11\"]\nversion = [\"42\", \"3.14\"]\n\n[[envs.test.matrix]]\npython = [\"3.11\", \"3.12\"]\nversion = [\"9000\"]\nfeature = [\"foo\", \"bar\"]\nUsing the env show command would then display:
$ hatch env show --ascii\n Standalone\n+---------+---------+\n| Name | Type |\n+=========+=========+\n| default | virtual |\n+---------+---------+\n Matrices\n+------+---------+----------------------+--------------+\n| Name | Type | Envs | Dependencies |\n+======+=========+======================+==============+\n| test | virtual | test.py3.10-42 | pytest |\n| | | test.py3.10-3.14 | |\n| | | test.py3.11-42 | |\n| | | test.py3.11-3.14 | |\n| | | test.py3.11-9000-foo | |\n| | | test.py3.11-9000-bar | |\n| | | test.py3.12-9000-foo | |\n| | | test.py3.12-9000-bar | |\n+------+---------+----------------------+--------------+\nYou can remove a single environment or environment matrix by using the env remove command or all of a project's environments by using the env prune command.
- name: Install Hatch\n uses: pypa/hatch@install\nRefer to the official action for more information.
"},{"location":"install/#installers","title":"Installers","text":"macOSWindows GUI installerCommand line installer- In your browser, download the
.pkgfile: hatch-universal.pkg - Run your downloaded file and follow the on-screen instructions.
- Restart your terminal.
-
To verify that the shell can find and run the
hatchcommand in yourPATH, use the following command.$ hatch --version\n1.13.0\n
-
Download the file using the
curlcommand. The-ooption specifies the file name that the downloaded package is written to. In this example, the file is written tohatch-universal.pkgin the current directory.curl -Lo hatch-universal.pkg https://github.com/pypa/hatch/releases/latest/download/hatch-universal.pkg\n -
Run the standard macOS
installerprogram, specifying the downloaded.pkgfile as the source. Use the-pkgparameter to specify the name of the package to install, and the-target /parameter for the drive in which to install the package. The files are installed to/usr/local/hatch, and an entry is created at/etc/paths.d/hatchthat instructs shells to add the/usr/local/hatchdirectory to. You must include sudo on the command to grant write permissions to those folders.sudo installer -pkg ./hatch-universal.pkg -target /\n -
Restart your terminal.
-
To verify that the shell can find and run the
hatchcommand in yourPATH, use the following command.$ hatch --version\n1.13.0\n
- In your browser, download one the
.msifiles:- hatch-x64.msi
- Run your downloaded file and follow the on-screen instructions.
- Restart your terminal.
-
To verify that the shell can find and run the
hatchcommand in yourPATH, use the following command.$ hatch --version\n1.13.0\n
-
Download and run the installer using the standard Windows
x64x86msiexecprogram, specifying one of the.msifiles as the source. Use the/passiveand/iparameters to request an unattended, normal installation.msiexec /passive /i https://github.com/pypa/hatch/releases/latest/download/hatch-x64.msi\nmsiexec /passive /i https://github.com/pypa/hatch/releases/latest/download/hatch-x86.msi\n -
Restart your terminal.
-
To verify that the shell can find and run the
hatchcommand in yourPATH, use the following command.$ hatch --version\n1.13.0\n
After downloading the archive corresponding to your platform and architecture, extract the binary to a directory that is on your PATH and rename to hatch.
- hatch-aarch64-unknown-linux-gnu.tar.gz
- hatch-x86_64-unknown-linux-gnu.tar.gz
- hatch-x86_64-unknown-linux-musl.tar.gz
- hatch-powerpc64le-unknown-linux-gnu.tar.gz
- hatch-aarch64-apple-darwin.tar.gz
- hatch-x86_64-apple-darwin.tar.gz
- hatch-x86_64-pc-windows-msvc.zip
- hatch-i686-pc-windows-msvc.zip
Hatch is available on PyPI and can be installed with pip.
pip install hatch\nWarning
This method modifies the Python environment in which you choose to install. Consider instead using pipx to avoid dependency conflicts.
"},{"location":"install/#pipx","title":"pipx","text":"pipx allows for the global installation of Python applications in isolated environments.
pipx install hatch\nSee the formula for more details.
brew install hatch\nSee the feedstock for more details.
conda install -c conda-forge hatch\nor with mamba:
mamba install hatch\nWarning
This method modifies the Conda environment in which you choose to install. Consider instead using pipx or condax to avoid dependency conflicts.
"},{"location":"install/#macports","title":"MacPorts","text":"See the port for more details.
sudo port install hatch\nThe minimum supported version is 37, currently in development as Rawhide.
sudo dnf install hatch\nxbps-install hatch\nHatchling is Hatch's build backend which you will never need to install manually. See its changelog for version information.
"},{"location":"intro/","title":"Introduction","text":""},{"location":"intro/#setup","title":"Setup","text":"Projects can be set up for use by Hatch using the new command.
Let's say you want to create a project named Hatch Demo. You would run:
hatch new \"Hatch Demo\"\nThis would create the following structure in your current working directory:
hatch-demo\n\u251c\u2500\u2500 src\n\u2502 \u2514\u2500\u2500 hatch_demo\n\u2502 \u251c\u2500\u2500 __about__.py\n\u2502 \u2514\u2500\u2500 __init__.py\n\u251c\u2500\u2500 tests\n\u2502 \u2514\u2500\u2500 __init__.py\n\u251c\u2500\u2500 LICENSE.txt\n\u251c\u2500\u2500 README.md\n\u2514\u2500\u2500 pyproject.toml\nTip
There are many ways to customize project generation.
"},{"location":"intro/#existing-project","title":"Existing project","text":"To initialize an existing project, enter the directory containing the project and run the following:
hatch new --init\nIf your project has a setup.py file the command will automatically migrate setuptools configuration for you. Otherwise, this will interactively guide you through the setup process.
Next you'll want to define more of your project's metadata located in the pyproject.toml file. You can specify things like its license, the supported versions of Python, and URLs referring to various parts of your project, like documentation.
The last step of the setup process is to define any dependencies that you'd like your project to begin with.
"},{"location":"intro/#configuration","title":"Configuration","text":"All project-specific configuration recognized by Hatch can be defined in either the pyproject.toml file, or a file named hatch.toml where options are not contained within the tool.hatch table:
[tool.hatch]\noption = \"...\"\n\n[tool.hatch.table1]\noption = \"...\"\n\n[tool.hatch.table2]\noption = \"...\"\noption = \"...\"\n\n[table1]\noption = \"...\"\n\n[table2]\noption = \"...\"\nTop level keys in the latter file take precedence when defined in both.
Tip
If you want to make your file more compact, you can use dotted keys, turning the above example into:
pyproject.toml hatch.toml[tool.hatch]\noption = \"...\"\ntable1.option = \"...\"\ntable2.option = \"...\"\noption = \"...\"\ntable1.option = \"...\"\ntable2.option = \"...\"\nAt this point you should have a basic understanding of how to use Hatch.
Now you may want to check out advanced configuration for environments or builds, set up your preferred shell, or read more about Hatch's CLI.
After that, check out the Hatch Showcase project to see examples of what is possible.
Finally, if you see a need, feel free to write a plugin for extended functionality.
"},{"location":"next-steps/#community","title":"Community","text":"For any projects using Hatch, you may add its official badge somewhere prominent like the README.
MarkdownreStructuredText[](https://github.com/pypa/hatch)\n.. image:: https://img.shields.io/badge/%F0%9F%A5%9A-Hatch-4051b5.svg\n :alt: Hatch project\n :target: https://github.com/pypa/hatch\nAfter your project is built, you can distribute it using the publish command.
The -p/--publisher option controls which publisher to use, with the default being index.
By default, the dist directory located at the root of your project will be used:
$ hatch publish\ndist/hatch_demo-1rc0-py3-none-any.whl ... success\ndist/hatch_demo-1rc0.tar.gz ... success\n\n[hatch-demo]\nhttps://pypi.org/project/hatch-demo/1rc0/\nYou can instead pass specific paths as arguments:
hatch publish /path/to/artifacts foo-1.tar.gz\nOnly files ending with .whl or .tar.gz will be published.
Please refer to the publisher plugin reference for configuration options.
There's a How-To on authentication and on options to select the target repository.
The publish command is implemented as a built-in plugin, if you're planning your own plugin, read about the publisher plugin API.
When the version is not statically set, configuration is defined in the tool.hatch.version table. The source option determines the source to use for retrieving and updating the version. The regex source is used by default.
The regex source requires an option path that represents a relative path to a file containing the project's version:
[tool.hatch.version]\npath = \"src/hatch_demo/__about__.py\"\n[version]\npath = \"src/hatch_demo/__about__.py\"\nThe default pattern looks for a variable named __version__ or VERSION that is set to a string containing the version, optionally prefixed with the lowercase letter v.
If this doesn't reflect how you store the version, you can define a different regular expression using the pattern option:
[tool.hatch.version]\npath = \"pkg/__init__.py\"\npattern = \"BUILD = 'b(?P<version>[^']+)'\"\n[version]\npath = \"pkg/__init__.py\"\npattern = \"BUILD = 'b(?P<version>[^']+)'\"\nThe pattern must have a named group called version that represents the version.
Invoking the version command without any arguments will display the current version of the project:
$ hatch version\n0.0.1\nYou can update the version like so:
$ hatch version \"0.1.0\"\nOld: 0.0.1\nNew: 0.1.0\nThe scheme option determines the scheme to use for parsing both the existing and new versions. The standard scheme is used by default, which is based on PEP 440.
Rather than setting the version explicitly, you can select the name of a segment used to increment the version:
$ hatch version minor\nOld: 0.1.0\nNew: 0.2.0\nYou can chain multiple segment updates with a comma. For example, if you wanted to release a preview of your project's first major version, you could do:
$ hatch version major,rc\nOld: 0.2.0\nNew: 1.0.0rc0\nWhen you want to release the final version, you would do:
$ hatch version release\nOld: 1.0.0rc0\nNew: 1.0.0\nHere are the supported segments and how they would influence an existing version of 1.0.0:
release 1.0.0 major 2.0.0 minor 1.1.0 micropatchfix 1.0.1 aalpha 1.0.0a0 bbeta 1.0.0b0 crcprepreview 1.0.0rc0 rrevpost 1.0.0.post0 dev 1.0.0.dev0"},{"location":"why/","title":"Why Hatch?","text":"The high level value proposition of Hatch is that if one adopts all functionality then many other tools become unnecessary since there is support for everything one might require. Further, if one chooses to use only specific features then there are still benefits compared to alternatives.
"},{"location":"why/#build-backend","title":"Build backend","text":"Hatchling, the build backend sister project, has many benefits compared to setuptools. Here we only compare setuptools as that is the one most people are familiar with.
- Better defaults: The default behavior for setuptools is often not desirable for the average user.
- For source distributions, setuptools has a custom enumeration of files that get included and excluded by default. Hatchling takes the defaults from your version control system such as Git's
.gitignorefile. - For wheels, setuptools attempts to find every directory that looks like a Python package. This is often undesirable as you might ship files to the end-user unintentionally such as test or tooling directories. Hatchling defaults to very specific inclusion based on the project name and errors if no heuristic is satisfied.
- For source distributions, setuptools has a custom enumeration of files that get included and excluded by default. Hatchling takes the defaults from your version control system such as Git's
- Ease of configurability: Hatchling was designed based on a history of significant challenges when configuring setuptools.
- Hatchling uses the same glob pattern syntax as Git itself for every option which is what most users are familiar with. On the other hand, setuptools uses shell-style glob patterns for source distributions while wheels use a mix of shell-style globs and Python package syntax.
- Configuring what gets included in source distributions requires a separate
MANIFEST.infile. The custom syntax and directives must be learned and it is difficult knowing which options in the main files likesetup.pyinfluence the behavior and under what conditions. For Hatchling, everything gets configured in a single file under dedicated sections for specific targets like[tool.hatch.build.targets.wheel]. - By default, non-Python files are excluded from wheels. Including such files requires usually verbose rules for every nested package directory. Hatchling makes no such distinction between file types and acts more like a general build system one might already be familiar with.
- Editable installations: The default behavior of Hatchling allows for proper static analysis by external tools such as IDEs. With setuptools, you must provide additional configuration which means that by default, for example, you would not get autocompletion in Visual Studio Code. This is marked as a legacy feature and may in fact be removed in future versions of setuptools.
- Reproducibility: Hatchling builds reproducible wheels and source distributions by default. setuptools does not support this for source distributions and there is no guarantee that wheels are reproducible.
- Extensibility: Although it is possible to extend setuptools, the API is quite low level. Hatchling has the concept of plugins that are separated into discrete types and only expose what is necessary, leading to an easier developer experience.
Why not?:
If building extension modules is required then it is recommended that you continue using setuptools, or even other backends that specialize in interfacing with compilers.
"},{"location":"why/#environment-management","title":"Environment management","text":"Here we compare to both tox and nox. At a high level, there are a few common advantages:
- Python management: Hatch is able to automatically download Python distributions on the fly when specific versions that environments request cannot be found. The alternatives will raise an error, with the option to ignore unknown distributions.
-
Philosophy: In the alternatives, environments are for the most part treated as executable units where a dependency set is associated with an action. If you are familiar with container ecosystems, this would be like defining a
CMDat the end of a Dockerfile but without the ability to change the action at runtime. This involves significant wasted disk space usually because one often requires slight modifications to the actions and therefore will define entirely different environments inherited from a base config just to perform different logic. Additionally, this can be confusing to users not just configuration-wise but also for execution of the different environments.In Hatch, environments are treated as isolated areas where you can execute arbitrary commands at runtime. For example, you can define a single test environment with named scripts that runs unit vs non-unit tests, each command being potentially very long but named however you wish so you get to control the interface. Since environments are treated as places where work is performed, you can also spawn a shell into any which will execute a subprocess that automatically drops into your shell of choice. Your shell will be configured appropriately like
pythonon PATH being updated and the prompt being changed to reflect the chosen environment. -
Configuration:
noxconfig is defined in Python which often leads to increased verbosity and makes it challenging to onboard folks compared to a standardized format with known behaviors.
- Extensibility:
toxallows for extending most aspects of its functionality however the API is so low-level and attached to internals that creating plugins may be challenging. For example, here is atoxplugin that was migrated to an equivalent Hatch environment collector plugin.noxis configured with Python so for the local project you can do whatever you want, however there is no concept of third-party plugins per se. To achieve that, you must usually use a package that wrapsnoxand use that package's imports instead (example).
Why not?:
If you are using nox and you wish to migrate, and for some reason you notify sessions, then migration wouldn't be a straight translation but rather you might have to redesign that conditional step.
Here we compare Python management to that of pyenv.
- Cross-platform: Hatch allows for the same experience no matter the system whereas
pyenvdoes not support Windows so you must use an entirely different project that tries to emulate the functionality. - No build dependencies: Hatch guarantees that every available distribution is prebuilt whereas the alternative requires one to maintain a precise build environment which differs by platform and potentially Python version. Another benefit to this is extremely fast installations since the distributions are simply downloaded and unpacked.
- Optimized by default: The CPython distributions are built with profile guided optimization and link-time optimization, resulting in a 10-30% performance improvement depending on the workload. These distributions have seen wide adoption throughout the industry and are even used by the build system Bazel.
- Simplicity: Hatch treats Python installations as just another directory that one would add to PATH. It can do this for you or you can manage PATH yourself, even allowing for custom install locations. On the other hand,
pyenvoperates by adding shims which then act as wrappers around the actual underlying binaries. This has many unfortunate side effects:- It is incumbent upon the user to manage which specific Python comes first via the CLI, switch when necessary, and/or have a mental model of which versions are exposed globally and locally per-project. This can become confusing quite quickly. When working with Hatch, your global Python installations are only important insofar as they are on PATH somewhere since environments do not use them directly but rather create virtual environments from them, always using a version that is compatible with your project.
- Configuration is required for each shell to properly set up
pyenvon start, leading to inconsistencies when running processes that do not spawn a shell. - Debugging issues with Python search paths can be extremely difficult, especially for users of software. If you or users have ever ran into an issue where code was being executed that you did not anticipate, the issue is almost always
pyenvinfluencing thepythonon PATH.
Why not?:
Currently, Hatch does not allow for the installation of specific patch release versions but rather only uses minor release granularity that tracks the latest patch release. If specific patch releases are important to you then it is best to use an alternative installation mechanism.
"},{"location":"blog/","title":"Blog","text":""},{"location":"blog/2024/05/02/hatch-v1100/","title":"Hatch v1.10.0","text":"Hatch v1.10.0 brings a test command, support for UV, and a Python script runner.
"},{"location":"blog/2024/05/02/hatch-v1100/#test-command","title":"Test command","text":"The new test command allows you to easily run tests for your project on multiple versions of Python. The default behavior follows best practices, using pytest with select plugins for test execution and coverage.py for code coverage measurement.
The command is designed to be both simple to use while also satisfying the needs of most projects. For example, the following shows Hatch running tests for Jinja in all environments in the default matrix:
Here is us testing Rich, with a bit of configuration:
See the tutorial for a detailed walk-through and the config reference for options.
"},{"location":"blog/2024/05/02/hatch-v1100/#uv","title":"UV","text":"The package installer UV, brought to you by the same folks behind Ruff, is now supported. In any environment, you can set the installer option to uv to use UV in place of virtualenv & pip for virtual environment creation and dependency management, respectively. This often results in a significant performance benefit.
For example, if you wanted to enable this functionality for the default environment, you could set the following:
pyproject.toml hatch.toml[tool.hatch.envs.default]\ninstaller = \"uv\"\n[envs.default]\ninstaller = \"uv\"\nSemi-internal environments like those used for testing and static analysis have this enabled by default.
See the how-to guide for more information about switching the installer.
"},{"location":"blog/2024/05/02/hatch-v1100/#python-script-runner","title":"Python script runner","text":"The run command now supports executing Python scripts with inline metadata as standardized by PEP 723.
As an example, consider the following script:
script.py# /// script\n# requires-python = \">=3.11\"\n# dependencies = [\n# \"httpx\",\n# \"rich\",\n# ]\n# ///\n\nimport httpx\nfrom rich.pretty import pprint\n\nresp = httpx.get(\"https://peps.python.org/api/peps.json\")\ndata = resp.json()\npprint([(k, v[\"title\"]) for k, v in data.items()][:10])\nIf you run the script for the first time as follows:
hatch run script.py\nHatch will create a dedicated environment for that script using a version of Python greater than or equal to 3.11 with dependencies httpx and rich.
See the how-to guide for more information.
"},{"location":"blog/2024/05/02/hatch-v1100/#static-analysis","title":"Static analysis","text":"The environment used for static analysis is now completely configurable such that you can fully alter the underlying behavior of the fmt command (see the how-to).
Additionally, Ruff has been updated to version 1.4.0 and the rules selected by default have been updated accordingly. Check out their blog post about how the new hand-written parser has made it twice as fast!
"},{"location":"blog/2024/05/02/hatch-v1100/#community-highlights","title":"Community highlights","text":""},{"location":"blog/2024/05/02/hatch-v1100/#visual-studio-code","title":"Visual Studio Code","text":"Visual Studio Code announced support for Hatch environments in their latest release. This means that you can now easily discover and select Hatch environments for your projects directly from the editor.
See the how-to guide for detailed instructions.
"},{"location":"blog/2024/05/02/hatch-v1100/#cmake-build-plugin","title":"CMake build plugin","text":"A new release of the extension module builder scikit-build-core has introduced a build plugin for Hatchling. This means that you can use Hatchling as your build backend while also shipping extension modules built with CMake.
To get started, add the dependency to your build requirements:
pyproject.toml[build-system]\nrequires = [\"hatchling>=1.24.2\", \"scikit-build-core~=0.9.3\"]\nbuild-backend = \"hatchling.build\"\nThen explicitly enable the experimental option (acknowledging that the plugin will move to a dedicated package in the future):
[tool.hatch.build.targets.wheel.hooks.scikit-build]\nexperimental = true\n[build.targets.wheel.hooks.scikit-build]\nexperimental = true\nAt this point, you can create your CMakeLists.txt file as usual and start building your extension modules with CMake! Check out the dedicated example project for a complete demonstration.
The efforts toward documentation improvements have increased substantially and the priorities have shifted. From now on expect to see far more tutorials and how-to guides rather than just reference material.
"},{"location":"blog/2024/05/02/hatch-v1100/#future","title":"Future","text":"Upcoming features include:
- workspaces functionality similar to Cargo
- commands to manage dependencies
- Windows release artifacts signed by the PSF (just like macOS)
- performance improvements for both the CLI and the Hatchling build system
If you or your organization finds value in what Hatch provides, consider a sponsorship to assist with maintenance and more rapid development!
"},{"location":"blog/2022/10/08/hatch-v160/","title":"Hatch v1.6.0","text":"Hatch v1.6.0 brings improvements to build environments, better handling of dynamic metadata, and support for tools like Visual Studio Code.
"},{"location":"blog/2022/10/08/hatch-v160/#build-environments","title":"Build environments","text":"Originally, the environment interface method for providing builder sub-environments was intended to be used in conjunction with some cleanup logic in order to provide a fresh setup every time. However, this is unnecessary in practice because build dependencies rarely change.
Without caching, repeat build environment use is slow which affects the following scenarios:
- the
buildcommand - commands that read project metadata, like
dep hash, if any fields are set dynamically
Now a new environment interface method build_environment_exists is used by Hatch to determine whether or not it has already been created, for implementations that have a caching mechanism.
The virtual environment type now uses this method to cache build environments.
Dynamically defined metadata is now supported everywhere, thanks to the new caching of virtual build environments.
A project metadata command is introduced that displays the fully resolved metadata. The output format is JSON unless a field is specified as an argument.
For example, if you checkout a project that is built by Hatch, like FastAPI, and run:
hatch project metadata readme\nonly the readme text will be displayed. If the content is in Markdown, then Rich will render it directly in your terminal:
The virtual environment type now uses a flat layout for storage in the configured virtual environment directory if the directory resides somewhere within the project root or if it is set to a .virtualenvs directory within the user's home directory.
For example, if you define the following Hatch configuration:
config.toml[dirs.env]\nvirtual = \".hatch\"\nand the following matrix:
pyproject.toml hatch.toml[[tool.hatch.envs.test.matrix]]\npython = [\"3.7\", \"3.8\", \"3.9\", \"3.10\", \"3.11\"]\n[[envs.test.matrix]]\npython = [\"3.7\", \"3.8\", \"3.9\", \"3.10\", \"3.11\"]\nthen locating environments with the following command:
hatch env find test\nwill show that the general directory structure is:
.hatch\n\u251c\u2500\u2500 test.py3.7\n\u251c\u2500\u2500 test.py3.8\n\u251c\u2500\u2500 test.py3.9\n\u251c\u2500\u2500 test.py3.10\n\u2514\u2500\u2500 test.py3.11\nThis flat structure is required for detection of virtual environments by tools like Visual Studio Code and PyCharm.
Additionally, the virtual environment type now supports a path option to specify an explicit path that all inherited environments will share, such as the common .venv.
The script used to migrate existing projects from setuptools has been improved to handle more edge cases that were encountered in the wild and now no longer modifies the formatting of existing pyproject.toml configuration.
Hatch now depends on Hatchling v1.11.0, which was also just released.
"},{"location":"blog/2022/10/08/hatch-v160/#environment-version-source","title":"Environment version source","text":"A new env version source is available that allows for the project version to be defined by an environment variable.
The standard version scheme now supports a validate-bump option that when set to false will forego the check when updating the version that the desired version is higher than the current version.
This use case comes from Project Jupyter:
A common pattern we use in Jupyter is to bump to a .dev0 minor version bump after making a release. If we have a bug fix that needs to go out in the interim, we'd rather not be forced to create a branch every time.
Hatch v1.8.0 brings Python distribution management, static analysis and formatting backed by Ruff, and binaries for every platform.
"},{"location":"blog/2023/12/11/hatch-v180/#installation-made-easy","title":"Installation made easy","text":"One thing that has been a perpetual problem for Hatch and other Python applications is that Python itself is a dependency. You, and more importantly your users, need to in some way get Python before your software can even be used. The recommended way to go about that is platform-dependent and even differs based on your target audience. I viewed this as a central UX problem for Hatch and so severe that I took a bit of a hiatus to solve it.
Luckily, I have to my satisfaction solved this problem in the form of PyApp. It is a runtime installer for Python projects written in Rust. Apps are distributed as standalone executables as users have come to expect and bootstrapping occurs upon the first invocation. Here is an example of what you would see the first time you run a binary from this release:
Now that we have binaries, creating installers for different platforms becomes trivial. Starting with this release not only are binaries available for every platform but also we have installers for Windows and macOS. The installer for macOS is signed using a certificate from the same account used to sign the official distributions from https://www.python.org, so users will not get any security pop-ups. Shout out to @ewdurbin for their extreme generosity in setting up multiple certificates in their free time!
These installers and binaries are now the recommended way to install and update Hatch. These binaries have built-in management so you can update to the latest version by running hatch self update.
Windows signing
In future we will sign the installers for Windows but I did not have time to look into how that works. macOS signing took way longer than I anticipated
"},{"location":"blog/2023/12/11/hatch-v180/#python-management","title":"Python management","text":"For a long time I and other users have desired that Hatch gain the ability to manage Python distributions. In my mind this was always blocked on a better installation experience because there was sort of a chicken-or-egg problem where you want a Python manager but you first need Python. No longer is that the case!
The new python command group allows for easy installation of various distributions to arbitrary locations which are then added to your PATH by default. Hatch supports CPython and PyPy distributions:
The virtual environment type is now far more intelligent when resolving the parent distribution to use and guarantees that, when no specific version is requested, the resolved distribution will always be compatible with the project.
Additionally, when a requested version cannot be found on PATH it will automatically be downloaded and managed internally.
"},{"location":"blog/2023/12/11/hatch-v180/#static-analysis","title":"Static analysis","text":"There is a new fmt command, backed entirely by Ruff, that checks and fixes your code for formatting and linting issues.
Starting with this release, Hatch maintains default settings that are guaranteed to be up-to-date and represent best practices for programming in modern Python. The idea is to provide defaults that are so broadly applicable that the majority of users will maintain little if any of their own overrides.
The default behavior is internal management of settings to provide an OOTB experience that works. It is recommended however that you persist the default config file in version control so that other tools like IDEs can utilize your full configuration.
Since Ruff is now provided as a built-in feature, new project templates no longer have such configuration and are much less verbose.
"},{"location":"blog/2023/12/11/hatch-v180/#build-improvements","title":"Build improvements","text":"Building projects that do not use Hatchling as a backend is now supported and such builds are managed with the standard build tool.
The bridge between Hatch and the Hatchling CLI has been removed. Previously, the builder would send serialized messages to Hatch that would contain the desired content and style for each line of output. This was done in an effort to allow builder and build hook plugins to output pretty messages without actually requiring a dependency like Rich. A problem that arises with this is that builders that invoke subprocesses will not display ANSI codes as one might expect and will lose out on the interactive experience of such invocations, like the built-in binary builder plugin calling cargo build. So now everything is simpler at the expense of no colored output without manual logic, or adding a dependency if you're a third-party plugin.
Spawning a shell or running commands within environments always first checks that your project's dependencies are satisfied and if not synchronizes the environment with what is defined. Previously, this had the potential to be quite slow for projects that have many dependencies.
Now the set of dependency definitions is hashed and no check is performed if the hash is the same as before, significantly speeding up environment usage in most cases.
"},{"location":"blog/2023/12/11/hatch-v180/#hatchling","title":"Hatchling","text":"Hatch now depends on Hatchling v1.19.0, which was also just released.
"},{"location":"blog/2023/12/11/hatch-v180/#better-defaults","title":"Better defaults","text":"Hatchling is all about providing the best possible defaults, even at the expense of backward compatibility. In this release, there are two breaking changes that provide a much better user experience and were in fact requested by users.
- Both the
force-includeoption and theforce_include_editablewheel build data setting now raise errors if source paths do not exist. - The
wheelbuild target now raises an error when no file inclusion options have been defined and none of its heuristics to determine what to ship are satisfied.
A new binary build target is now stable that allows for the building of standalone binaries for projects. This is what Hatch itself uses for its binaries.
A new page has been introduced that discusses the value proposition of Hatch and Hatchling in comparison to alternatives. Currently, it only addresses a few features but in future this page will become more comprehensive.
"},{"location":"blog/2023/12/11/hatch-v180/#future","title":"Future","text":"Upcoming features include a test command, commands to manage dependencies, and workspaces functionality similar to Cargo that will make managing monorepos far easier.
Next year there will be two large efforts that you should expect to see:
-
A significant amount of my free time (and some at work) will be devoted to introducing lock file functionality in Hatch and trying to get whatever that happens to be standardized.
I met with @brettcannon about his thoughts post-PEP 665 and about mousebender. I also met with the prefix.dev team about rip and was fortunate enough to be shown a demo before its official announcement.
At the moment, the two options I see are to either go all in and contribute to mousebender or rely on the Prefix folks and use rip. The latter has the benefit of potentially supporting Conda as a side effect with the downside of being quite new with the spec firmly out of our control. The former has the benefit of being able to easily gain institutional support from the Python packaging team and each of our employers with the downside being a significant amount of work needing to be done.
-
When @henryiii is able to get some free time away from teaching I plan to work with him once again and push very hard for the Python build ecosystem to adopt the extensionlib approach.
I am of the opinion that the Python community has not fully completed the expressed outcome of PEP 517 in that build backends are still (for the most part) reliant on setuptools for building non-Python code bases.
Basically, there are components that interact with compilers to produce extension modules and components that pack files into an archive which we call a build backend. These are two distinct pieces of functionality and my view is that there should be an API that allows backends to consume extension module builders to find out where things got created and where they should be shipped inside archives.
In this hypothetical future any build backend would be able to trigger the building of extension modules based on user configuration.
If you or your organization finds value in what Hatch provides, consider a sponsorship to assist with maintenance and more rapid development!
"},{"location":"blog/2023/12/18/hatch-v190/","title":"Hatch v1.9.0","text":"Hatch v1.9.0 brings improvements to static analysis and important bug fixes.
"},{"location":"blog/2023/12/18/hatch-v190/#static-analysis","title":"Static analysis","text":"The default version of Ruff has been increased to v0.1.8. This release brings formatting capabilities to docstrings and Hatch enables this by default with line length set to 80. This length was chosen as the default because it plays nicely with the rendering of the most popular themes for Python documentation, such as Material for MkDocs and Furo.
Additionally, it is now possible for projects to pin to specific versions of Ruff for upgrading at a later time:
pyproject.toml hatch.toml[tool.hatch.envs.hatch-static-analysis]\ndependencies = [\"ruff==X.Y.Z\"]\n[envs.hatch-static-analysis]\ndependencies = [\"ruff==X.Y.Z\"]\n- Python resolution for environments that do not install the project is no longer bound by the project's Python requirement.
- Fixed an edge case for out-of-the-box static analysis when there was existing configuration.
- Compatibility checks for environments no longer occur if the environment is already created. This significantly increases the responsiveness of environment usage.
The amount of displayed output is controlled solely by the -v/--verbose (environment variable HATCH_VERBOSE) and -q/--quiet (environment variable HATCH_QUIET) root options.
The levels are documented here.
"},{"location":"cli/about/#project-awareness","title":"Project awareness","text":"No matter the mode, Hatch will always change to the project's root directory for entering or running commands in environments.
"},{"location":"cli/about/#tab-completion","title":"Tab completion","text":"Completion is achieved by saving a script and then executing it as a part of your shell's startup sequence.
Afterward, you'll need to start a new shell in order for the changes to take effect.
BashZ shellfishSave the script somewhere:
_HATCH_COMPLETE=bash_source hatch > ~/.hatch-complete.bash\nSource the file in ~/.bashrc (or ~/.bash_profile if on macOS):
. ~/.hatch-complete.bash\nSave the script somewhere:
_HATCH_COMPLETE=zsh_source hatch > ~/.hatch-complete.zsh\nSource the file in ~/.zshrc:
. ~/.hatch-complete.zsh\nSave the script in ~/.config/fish/completions:
_HATCH_COMPLETE=fish_source hatch > ~/.config/fish/completions/hatch.fish\nUsage:
hatch [OPTIONS] COMMAND [ARGS]...\nOptions:
Name Type Description Default--env, -e text The name of the environment to use [env var: HATCH_ENV] default --project, -p text The name of the project to work on [env var: HATCH_PROJECT] None --verbose, -v integer range (0 and above) Increase verbosity (can be used additively) [env var: HATCH_VERBOSE] 0 --quiet, -q integer range (0 and above) Decrease verbosity (can be used additively) [env var: HATCH_QUIET] 0 --color / --no-color boolean Whether or not to display colored output (default is auto-detection) [env vars: FORCE_COLOR/NO_COLOR] None --interactive / --no-interactive boolean Whether or not to allow features like prompts and progress bars (default is auto-detection) [env var: HATCH_INTERACTIVE] None --data-dir text The path to a custom directory used to persist data [env var: HATCH_DATA_DIR] None --cache-dir text The path to a custom directory used to cache data [env var: HATCH_CACHE_DIR] None --config text The path to a custom config file to use [env var: HATCH_CONFIG] None --version boolean Show the version and exit. False --help boolean Show this message and exit. False"},{"location":"cli/reference/#hatch-build","title":"hatch build","text":"Build a project.
Usage:
hatch build [OPTIONS] [LOCATION]\nOptions:
Name Type Description Default--target, -t text The target to build, overriding project defaults. This may be selected multiple times e.g. -t sdist -t wheel None --hooks-only boolean Whether or not to only execute build hooks [env var: HATCH_BUILD_HOOKS_ONLY] False --no-hooks boolean Whether or not to disable build hooks [env var: HATCH_BUILD_NO_HOOKS] False --ext boolean Whether or not to only execute build hooks for distributing binary Python packages, such as compiling extensions. Equivalent to --hooks-only -t wheel False --clean, -c boolean Whether or not existing artifacts should first be removed [env var: HATCH_BUILD_CLEAN] False --clean-hooks-after boolean Whether or not build hook artifacts should be removed after each build [env var: HATCH_BUILD_CLEAN_HOOKS_AFTER] False --help boolean Show this message and exit. False"},{"location":"cli/reference/#hatch-clean","title":"hatch clean","text":"Remove build artifacts.
Usage:
hatch clean [OPTIONS] [LOCATION]\nOptions:
Name Type Description Default--target, -t text The target with which to remove artifacts, overriding project defaults. This may be selected multiple times e.g. -t sdist -t wheel None --hooks-only boolean Whether or not to only remove artifacts from build hooks [env var: HATCH_BUILD_HOOKS_ONLY] False --no-hooks boolean Whether or not to ignore artifacts from build hooks [env var: HATCH_BUILD_NO_HOOKS] False --ext boolean Whether or not to only remove artifacts from build hooks for distributing binary Python packages, such as compiled extensions. Equivalent to --hooks-only -t wheel False --help boolean Show this message and exit. False"},{"location":"cli/reference/#hatch-config","title":"hatch config","text":"Manage the config file
Usage:
hatch config [OPTIONS] COMMAND [ARGS]...\nOptions:
Name Type Description Default--help boolean Show this message and exit. False"},{"location":"cli/reference/#hatch-config-explore","title":"hatch config explore","text":"Open the config location in your file manager.
Usage:
hatch config explore [OPTIONS]\nOptions:
Name Type Description Default--help boolean Show this message and exit. False"},{"location":"cli/reference/#hatch-config-find","title":"hatch config find","text":"Show the location of the config file.
Usage:
hatch config find [OPTIONS]\nOptions:
Name Type Description Default--help boolean Show this message and exit. False"},{"location":"cli/reference/#hatch-config-restore","title":"hatch config restore","text":"Restore the config file to default settings.
Usage:
hatch config restore [OPTIONS]\nOptions:
Name Type Description Default--help boolean Show this message and exit. False"},{"location":"cli/reference/#hatch-config-set","title":"hatch config set","text":"Assign values to config file entries. If the value is omitted, you will be prompted, with the input hidden if it is sensitive.
Usage:
hatch config set [OPTIONS] KEY [VALUE]\nOptions:
Name Type Description Default--help boolean Show this message and exit. False"},{"location":"cli/reference/#hatch-config-show","title":"hatch config show","text":"Show the contents of the config file.
Usage:
hatch config show [OPTIONS]\nOptions:
Name Type Description Default--all, -a boolean Do not scrub secret fields False --help boolean Show this message and exit. False"},{"location":"cli/reference/#hatch-config-update","title":"hatch config update","text":"Update the config file with any new fields.
Usage:
hatch config update [OPTIONS]\nOptions:
Name Type Description Default--help boolean Show this message and exit. False"},{"location":"cli/reference/#hatch-dep","title":"hatch dep","text":"Manage environment dependencies
Usage:
hatch dep [OPTIONS] COMMAND [ARGS]...\nOptions:
Name Type Description Default--help boolean Show this message and exit. False"},{"location":"cli/reference/#hatch-dep-hash","title":"hatch dep hash","text":"Output a hash of the currently defined dependencies.
Usage:
hatch dep hash [OPTIONS]\nOptions:
Name Type Description Default--project-only, -p boolean Whether or not to exclude environment dependencies False --env-only, -e boolean Whether or not to exclude project dependencies False --help boolean Show this message and exit. False"},{"location":"cli/reference/#hatch-dep-show","title":"hatch dep show","text":"Display dependencies in various formats
Usage:
hatch dep show [OPTIONS] COMMAND [ARGS]...\nOptions:
Name Type Description Default--help boolean Show this message and exit. False"},{"location":"cli/reference/#hatch-dep-show-requirements","title":"hatch dep show requirements","text":"Enumerate dependencies as a list of requirements.
Usage:
hatch dep show requirements [OPTIONS]\nOptions:
Name Type Description Default--project-only, -p boolean Whether or not to exclude environment dependencies False --env-only, -e boolean Whether or not to exclude project dependencies False --feature, -f text Whether or not to only show the dependencies of the specified features None --all boolean Whether or not to include the dependencies of all features False --help boolean Show this message and exit. False"},{"location":"cli/reference/#hatch-dep-show-table","title":"hatch dep show table","text":"Enumerate dependencies in a tabular format.
Usage:
hatch dep show table [OPTIONS]\nOptions:
Name Type Description Default--project-only, -p boolean Whether or not to exclude environment dependencies False --env-only, -e boolean Whether or not to exclude project dependencies False --lines, -l boolean Whether or not to show lines between table rows False --ascii boolean Whether or not to only use ASCII characters False --help boolean Show this message and exit. False"},{"location":"cli/reference/#hatch-env","title":"hatch env","text":"Manage project environments
Usage:
hatch env [OPTIONS] COMMAND [ARGS]...\nOptions:
Name Type Description Default--help boolean Show this message and exit. False"},{"location":"cli/reference/#hatch-env-create","title":"hatch env create","text":"Create environments.
Usage:
hatch env create [OPTIONS] [ENV_NAME]\nOptions:
Name Type Description Default--help boolean Show this message and exit. False"},{"location":"cli/reference/#hatch-env-find","title":"hatch env find","text":"Locate environments.
Usage:
hatch env find [OPTIONS] [ENV_NAME]\nOptions:
Name Type Description Default--help boolean Show this message and exit. False"},{"location":"cli/reference/#hatch-env-prune","title":"hatch env prune","text":"Remove all environments.
Usage:
hatch env prune [OPTIONS]\nOptions:
Name Type Description Default--help boolean Show this message and exit. False"},{"location":"cli/reference/#hatch-env-remove","title":"hatch env remove","text":"Remove environments.
Usage:
hatch env remove [OPTIONS] [ENV_NAME]\nOptions:
Name Type Description Default--help boolean Show this message and exit. False"},{"location":"cli/reference/#hatch-env-run","title":"hatch env run","text":"Run commands within project environments.
The -e/--env option overrides the equivalent root option and the HATCH_ENV environment variable.
The -i/--include and -x/--exclude options may be used to include or exclude certain variables, optionally followed by specific comma-separated values, and may be selected multiple times. For example, if you have the following configuration:
[[tool.hatch.envs.test.matrix]]\npython = [\"3.9\", \"3.10\"]\nversion = [\"42\", \"3.14\", \"9000\"]\n[[envs.test.matrix]]\npython = [\"3.9\", \"3.10\"]\nversion = [\"42\", \"3.14\", \"9000\"]\nthen running:
hatch env run -i py=3.10 -x version=9000 test:pytest\nwould execute pytest in the environments test.py3.10-42 and test.py3.10-3.14. Note that py may be used as an alias for python.
Note
The inclusion option is treated as an intersection while the exclusion option is treated as a union i.e. an environment must match all of the included variables to be selected while matching any of the excluded variables will prevent selection.
Usage:
hatch env run [OPTIONS] ARGS...\nOptions:
Name Type Description Default--env, -e text The environments to target None --include, -i text The matrix variables to include None --exclude, -x text The matrix variables to exclude None --filter, -f text The JSON data used to select environments None --force-continue boolean Run every command and if there were any errors exit with the first code False --ignore-compat boolean Ignore incompatibility when selecting specific environments False --help boolean Show this message and exit. False"},{"location":"cli/reference/#hatch-env-show","title":"hatch env show","text":"Show the available environments.
Usage:
hatch env show [OPTIONS] [ENVS]...\nOptions:
Name Type Description Default--ascii boolean Whether or not to only use ASCII characters False --json boolean Whether or not to output in JSON format False --internal, -i boolean Show internal environments False --help boolean Show this message and exit. False"},{"location":"cli/reference/#hatch-fmt","title":"hatch fmt","text":"Format and lint source code.
Usage:
hatch fmt [OPTIONS] [ARGS]...\nOptions:
Name Type Description Default--check boolean Only check for errors rather than fixing them False --linter, -l boolean Only run the linter False --formatter, -f boolean Only run the formatter False --sync boolean Sync the default config file with the current version of Hatch False --help boolean Show this message and exit. False"},{"location":"cli/reference/#hatch-new","title":"hatch new","text":"Create or initialize a project.
Usage:
hatch new [OPTIONS] [NAME] [LOCATION]\nOptions:
Name Type Description Default--interactive, -i boolean Interactively choose details about the project False --cli boolean Give the project a command line interface False --init boolean Initialize an existing project False --help boolean Show this message and exit. False"},{"location":"cli/reference/#hatch-project","title":"hatch project","text":"View project information
Usage:
hatch project [OPTIONS] COMMAND [ARGS]...\nOptions:
Name Type Description Default--help boolean Show this message and exit. False"},{"location":"cli/reference/#hatch-project-metadata","title":"hatch project metadata","text":"Display project metadata.
If you want to view the raw readme file without rendering, you can use a JSON parser like jq:
hatch project metadata | jq -r .readme\nUsage:
hatch project metadata [OPTIONS] [FIELD]\nOptions:
Name Type Description Default--help boolean Show this message and exit. False"},{"location":"cli/reference/#hatch-publish","title":"hatch publish","text":"Publish build artifacts.
Usage:
hatch publish [OPTIONS] [ARTIFACTS]...\nOptions:
Name Type Description Default--repo, -r text The repository with which to publish artifacts [env var: HATCH_INDEX_REPO] None --user, -u text The user with which to authenticate [env var: HATCH_INDEX_USER] None --auth, -a text The credentials to use for authentication [env var: HATCH_INDEX_AUTH] None --ca-cert text The path to a CA bundle [env var: HATCH_INDEX_CA_CERT] None --client-cert text The path to a client certificate, optionally containing the private key [env var: HATCH_INDEX_CLIENT_CERT] None --client-key text The path to the client certificate's private key [env var: HATCH_INDEX_CLIENT_KEY] None --no-prompt, -n boolean Disable prompts, such as for missing required fields False --initialize-auth boolean Save first-time authentication information even if nothing was published False --publisher, -p text The publisher plugin to use (default is index) [env var: HATCH_PUBLISHER] index --option, -o text Options to pass to the publisher plugin. This may be selected multiple times e.g. -o foo=bar -o baz=23 [env var: HATCH_PUBLISHER_OPTIONS] None --yes, -y boolean Confirm without prompting when the plugin is disabled False --help boolean Show this message and exit. False"},{"location":"cli/reference/#hatch-python","title":"hatch python","text":"Manage Python installations
Usage:
hatch python [OPTIONS] COMMAND [ARGS]...\nOptions:
Name Type Description Default--help boolean Show this message and exit. False"},{"location":"cli/reference/#hatch-python-find","title":"hatch python find","text":"Locate Python binaries.
Usage:
hatch python find [OPTIONS] NAME\nOptions:
Name Type Description Default-p, --parent boolean Show the parent directory of the Python binary False --dir, -d text The directory in which distributions reside None --help boolean Show this message and exit. False"},{"location":"cli/reference/#hatch-python-install","title":"hatch python install","text":"Install Python distributions.
You may select all to install all compatible distributions:
hatch python install all\nYou can set custom sources for distributions by setting the HATCH_PYTHON_SOURCE_<NAME> environment variable where <NAME> is the uppercased version of the distribution name with periods replaced by underscores e.g. HATCH_PYTHON_SOURCE_PYPY3_10.
Usage:
hatch python install [OPTIONS] NAMES...\nOptions:
Name Type Description Default--private boolean Do not add distributions to the user PATH False --update, -u boolean Update existing installations False --dir, -d text The directory in which to install distributions, overriding configuration None --help boolean Show this message and exit. False"},{"location":"cli/reference/#hatch-python-remove","title":"hatch python remove","text":"Remove Python distributions.
You may select all to remove all installed distributions:
hatch python remove all\nUsage:
hatch python remove [OPTIONS] NAMES...\nOptions:
Name Type Description Default--dir, -d text The directory in which distributions reside None --help boolean Show this message and exit. False"},{"location":"cli/reference/#hatch-python-show","title":"hatch python show","text":"Show the available Python distributions.
Usage:
hatch python show [OPTIONS]\nOptions:
Name Type Description Default--ascii boolean Whether or not to only use ASCII characters False --dir, -d text The directory in which distributions reside None --help boolean Show this message and exit. False"},{"location":"cli/reference/#hatch-python-update","title":"hatch python update","text":"Update Python distributions.
You may select all to update all installed distributions:
hatch python update all\nUsage:
hatch python update [OPTIONS] NAMES...\nOptions:
Name Type Description Default--dir, -d text The directory in which distributions reside None --help boolean Show this message and exit. False"},{"location":"cli/reference/#hatch-run","title":"hatch run","text":"Run commands within project environments. This is a convenience wrapper around the env run command.
If the first argument contains a colon, then the preceding component will be interpreted as the name of the environment to target, overriding the -e/--env root option and the HATCH_ENV environment variable.
If the environment provides matrices, then you may also provide leading arguments starting with a + or - to select or exclude certain variables, optionally followed by specific comma-separated values. For example, if you have the following configuration:
[[tool.hatch.envs.test.matrix]]\npython = [\"3.9\", \"3.10\"]\nversion = [\"42\", \"3.14\", \"9000\"]\n[[envs.test.matrix]]\npython = [\"3.9\", \"3.10\"]\nversion = [\"42\", \"3.14\", \"9000\"]\nthen running:
hatch run +py=3.10 -version=9000 test:pytest\nwould execute pytest in the environments test.py3.10-42 and test.py3.10-3.14. Note that py may be used as an alias for python.
Note
Inclusions are treated as an intersection while exclusions are treated as a union i.e. an environment must match all of the included variables to be selected while matching any of the excluded variables will prevent selection.
Usage:
hatch run [OPTIONS] [ENV:]ARGS...\nOptions:
Name Type Description Default--help boolean Show this message and exit. False"},{"location":"cli/reference/#hatch-self","title":"hatch self","text":"Manage Hatch
Usage:
hatch self [OPTIONS] COMMAND [ARGS]...\nOptions:
Name Type Description Default--help boolean Show this message and exit. False"},{"location":"cli/reference/#hatch-self-report","title":"hatch self report","text":"Generate a pre-populated GitHub issue.
Usage:
hatch self report [OPTIONS]\nOptions:
Name Type Description Default--no-open, -n boolean Show the URL instead of opening it False --help boolean Show this message and exit. False"},{"location":"cli/reference/#hatch-self-restore","title":"hatch self restore","text":"Restore the installation
Usage:
hatch self restore [OPTIONS] [ARGS]...\nOptions:
Name Type Description Default--help boolean Show this message and exit. False"},{"location":"cli/reference/#hatch-self-update","title":"hatch self update","text":"Install the latest version
Usage:
hatch self update [OPTIONS] [ARGS]...\nOptions:
Name Type Description Default--help boolean Show this message and exit. False"},{"location":"cli/reference/#hatch-shell","title":"hatch shell","text":"Enter a shell within a project's environment.
Usage:
hatch shell [OPTIONS] [ENV_NAME]\nOptions:
Name Type Description Default--name text N/A None --path text N/A None --help boolean Show this message and exit. False"},{"location":"cli/reference/#hatch-status","title":"hatch status","text":"Show information about the current environment.
Usage:
hatch status [OPTIONS]\nOptions:
Name Type Description Default--help boolean Show this message and exit. False"},{"location":"cli/reference/#hatch-test","title":"hatch test","text":"Run tests using the hatch-test environment matrix.
If no filtering options are selected, then tests will be run in the first compatible environment found in the matrix with priority given to those matching the current interpreter.
The -i/--include and -x/--exclude options may be used to include or exclude certain variables, optionally followed by specific comma-separated values, and may be selected multiple times. For example, if you have the following configuration:
[[tool.hatch.envs.hatch-test.matrix]]\npython = [\"3.9\", \"3.10\"]\nversion = [\"42\", \"3.14\", \"9000\"]\n[[envs.hatch-test.matrix]]\npython = [\"3.9\", \"3.10\"]\nversion = [\"42\", \"3.14\", \"9000\"]\nthen running:
hatch test -i py=3.10 -x version=9000\nwould run tests in the environments hatch-test.py3.10-42 and hatch-test.py3.10-3.14.
The -py/--python option is a shortcut for specifying the inclusion -i py=....
Note
The inclusion option is treated as an intersection while the exclusion option is treated as a union i.e. an environment must match all of the included variables to be selected while matching any of the excluded variables will prevent selection.
Usage:
hatch test [OPTIONS] [ARGS]...\nOptions:
Name Type Description Default--randomize, -r boolean Randomize the order of test execution False --parallel, -p boolean Parallelize test execution False --retries integer Number of times to retry failed tests None --retry-delay float Seconds to wait between retries None --cover, -c boolean Measure code coverage False --cover-quiet boolean Disable coverage reporting after tests, implicitly enabling --cover False --all, -a boolean Test all environments in the matrix False --python, -py text The Python versions to test, equivalent to: -i py=... None --include, -i text The matrix variables to include None --exclude, -x text The matrix variables to exclude None --show, -s boolean Show information about environments in the matrix False --help boolean Show this message and exit. False"},{"location":"cli/reference/#hatch-version","title":"hatch version","text":"View or set a project's version.
Usage:
hatch version [OPTIONS] [DESIRED_VERSION]\nOptions:
Name Type Description Default--help boolean Show this message and exit. False"},{"location":"community/contributing/","title":"Contributing","text":"The usual process to make a contribution is to:
- Check for existing related issues
- Fork the repository and create a new branch
- Make your changes
- Make sure formatting, linting and tests passes.
- Add tests if possible to cover the lines you added.
- Commit, and send a Pull Request.
Clone the hatch repository, cd into it, and create a new branch for your contribution:
cd hatch\ngit checkout -b add-my-contribution\nRun the test suite while developing:
hatch run dev\nRun the test suite with coverage report:
hatch run cov\nRun the extended test suite with coverage:
hatch run full\nRun automated formatting:
hatch run lint:fmt\nRun full linting and type checking:
hatch run lint:all\nStart the documentation in development:
hatch run docs:serve\nBuild and validate the documentation website:
hatch run docs:build-check\n- Project Jupyter - https://blog.jupyter.org/packaging-for-jupyter-in-2022-c7be64c38926
- Visual Studio Code - https://code.visualstudio.com/updates/v1_88#_hatch-environment-discovery
- Black - https://ichard26.github.io/blog/2022/10/black-22.10.0/#goodbye-python-36-and-hello-hatchling
- \"Switching to Hatch\" - https://andrich.me/2023/08/switching-to-hatch/
The following is not intended to be a complete enumeration. Be sure to view the development version of this page for an up-to-date listing.
"},{"location":"community/users/#projects","title":"Projects","text":"aiogram | Apache Airflow | argon2-cffi | attrs | Black | coffea | Colorama | Django Anymail | Django Debug Toolbar | Django NYT | Django OTP | Django OTP Agents | Django OTP Twilio | Django OTP YubiKey | Django Places | Django Wiki | FastAPI | filelock | Fluentd | github3.py | Gradio | HTTPX | iCalendar for Humans | LinkChecker | Litestar | Material for MkDocs | MicroPython | MkDocs | openSUSE | Nox | Packit | pipx | platformdirs | Pydantic | Pygments | PyHamcrest | PyMdown Extensions | Python JSON Schema | Rye | SALib | Spack | Starlette | structlog | tox | Twisted | urllib3 | Uvicorn | virtualenv | Voil\u00e0 | XGBoost | Ypy | yt-dlp
"},{"location":"community/users/#industry","title":"Industry","text":"- Anaconda [1|2|3|4|5|6|7]
- Airbnb [1]
- Astronomer [1|2|3]
- Bitwarden [1]
- Bloomberg [1|2]
- Blue Robotics [1]
- Cars.com [1]
- Cisco [1|2]
- Databricks [1|2|3]
- Datadog [1|2|3|4]
- deepset [1|2]
- Elastic [1|2|3]
- Google [1|2|3|4|5|6]
- IBM [1]
- JPMorgan Chase [1]
- Intel Corporation [1|2|3]
- McKinsey [1|2]
- Meta [1|2|3]
- Microsoft [1|2|3|4|5|6]
- OpenAI [1]
- Oracle [1]
- Palo Alto Networks [1]
- Quansight [1]
- Red Hat [1|2|3|4|5]
- Salesforce [1]
- Snowflake [1]
- Splunk [1]
- The Westervelt Company [1|2|3|4|5|6]
- Virtru [1|2]
- VMware [1|2|3]
- Volvo Group [1]
- Free Ebook Foundation [1]
- Greater Paris University Hospitals (AP-HP) [1]
- Massachusetts General Hospital [1]
- Let's Encrypt [1]
- Max Planck Society [1]
- OpenTelemetry [1|2]
- Smithsonian Institution [1]
- The New York Public Library [1]
- European Molecular Biology Laboratory
- European Bioinformatics Institute [1]
- Germany
- Berlin Institute of Health [1]
- Helmholtz Munich [1|2]
- Norway
- Statistics Norway [1]
- United Kingdom
- The Alan Turing Institute [1]
- Department for Business and Trade [1]
- The National Archives [1]
- United States
- NASA [1]
- National Institute of Standards and Technology [1|2|3|4|5]
- National Security Agency [1|2]
- National Telecommunications and Information Administration [1|2|3|4]
- Brown University
- Carney Institute for Brain Science [1]
- Carnegie Mellon University
- Department of Chemical Engineering [1|2|3|4|5|6]
- Chinese Academy of Sciences
- Academy of Mathematics and Systems Science [1]
- Georgia Institute of Technology
- Georgia Tech Database Group [1]
- Harvard University
- Department of Molecular and Cellular Biology [1]
- Heidelberg University
- Center for Molecular Biology [1]
- Leiden University
- Leiden University Libraries [1|2]
- Maastricht University
- Institute of Data Science [1|2|3|4|5|6|7|8]
- Massachusetts Institute of Technology
- Computer Science and Artificial Intelligence Laboratory [1]
- Digital Humanities [1]
- Medical University of Innsbruck
- Institute of Bioinformatics [1]
- Polytechnique Montr\u00e9al
- Department of Computer Engineering and Software Engineering [1]
- Siberian Branch of the Russian Academy of Sciences
- Institute of Cytology and Genetics [1|2|3|4]
- Stanford University
- Empirical Security Research Group [1]
- University of British Columbia
- Department of Earth, Ocean and Atmospheric Sciences [1|2|3]
- University of California, Berkeley
- Center for Computational Biology [1]
- University of California, Santa Barbara
- Department of Computer Science [1]
- University of Freiburg
- Freiburg Center for Data Analysis and Modeling [1]
- University of Illinois Urbana-Champaign
- Grainger College of Engineering [1]
- University of Lausanne
- Department of Computational Biology [1]
- University of Ljubljana
- Faculty of Mechanical Engineering [1]
- University of Massachusetts Amherst
- College of Information and Computer Sciences [1]
- University of Oxford
- Oxford Research Software Engineering [1]
- University of Pennsylvania
- Lifespan Informatics and Neuroimaging Center [1|2|3|4]
- University of Regensburg
- Spang Lab [1]
- University of Sussex
- Predictive Analytics Lab [1]
- University of Toronto Scarborough
- utsc-networking [1|2|3|4]
- University of Washington
- Interactive Data Lab [1]
- Virtual Brain Lab [1]
- University of Wisconsin-Madison
- Data Science Institute [1]
- Waseda University
- Tackeuchi Laboratory [1|2|3|4|5]
- Wellcome Sanger Institute [1]
- Clariah [1]
- CloudDrift [1]
- Dask [1|2]
- GAMA [1]
- IPython [1|2|3]
- MNE [1|2|3]
- NIPY [1|2]
- Project Jupyter
- Jupyter [1|2|3|4]
- JupyterLab [1|2|3|4|5]
- Jupyter Server [1|2|3|4]
- RAPIDS [1]
- Scikit-HEP [1|2|3|4|5|6|7|8|9|10]
- scverse [1|2|3]
- Spyder [1]
"},{"location":"community/users/#security","title":"Security","text":"- Armory
- in-toto
- The Update Framework
- Ocean Protocol [1]
Build targets are defined as sections within
pyproject.toml hatch.tomltool.hatch.build.targets:[tool.hatch.build.targets.<TARGET_NAME>]\n[build.targets.<TARGET_NAME>]\nTip
Although not recommended, you may define global configuration in the
"},{"location":"config/build/#build-system","title":"Build system","text":"tool.hatch.buildtable. Keys may then be overridden by target config.To be compatible with the broader Python packaging ecosystem, you must define the build system as follows:
pyproject.toml[build-system]\nrequires = [\"hatchling\"]\nbuild-backend = \"hatchling.build\"\nThe version of
hatchlingdefined here will be used to build all targets.Hatchling is a standards-compliant1 build backend and is a dependency of Hatch itself.
"},{"location":"config/build/#file-selection","title":"File selection","text":""},{"location":"config/build/#vcs","title":"VCS","text":"By default, Hatch will respect the first
pyproject.toml hatch.toml.gitignoreor.hgignorefile found in your project's root directory or parent directories. Setignore-vcstotrueto disable this behavior:[tool.hatch.build.targets.sdist]\nignore-vcs = true\n[build.targets.sdist]\nignore-vcs = true\nNote
For
"},{"location":"config/build/#patterns","title":"Patterns","text":".hgignorefiles only glob syntax is supported.You can set the
includeandexcludeoptions to select exactly which files will be shipped in each build, withexcludetaking precedence. Every entry represents a Git-style glob pattern.For example, the following configuration:
pyproject.toml hatch.toml[tool.hatch.build.targets.sdist]\ninclude = [\n \"pkg/*.py\",\n \"/tests\",\n]\nexclude = [\n \"*.json\",\n \"pkg/_compat.py\",\n]\n[build.targets.sdist]\ninclude = [\n \"pkg/*.py\",\n \"/tests\",\n]\nexclude = [\n \"*.json\",\n \"pkg/_compat.py\",\n]\nwill exclude every file with a
"},{"location":"config/build/#artifacts","title":"Artifacts","text":".jsonextension, and will include everything under atestsdirectory located at the root and every file with a.pyextension that is directly under apkgdirectory located at the root except for_compat.py.If you want to include files that are ignored by your VCS, such as those that might be created by build hooks, you can use the
artifactsoption. This option is semantically equivalent toinclude.Note that artifacts are not affected by the
pyproject.toml hatch.tomlexcludeoption. Artifacts can be excluded by using more explicit paths or by using the!negation operator. When using the!operator, the negated pattern(s) must come after the more generic ones.[tool.hatch.build.targets.wheel]\nartifacts = [\n \"*.so\",\n \"*.dll\",\n \"!/foo/*.so\",\n]\n
"},{"location":"config/build/#explicit-selection","title":"Explicit selection","text":""},{"location":"config/build/#generic","title":"Generic","text":"[build.targets.wheel]\nartifacts = [\n \"*.so\",\n \"*.dll\",\n \"!/foo/*.so\",\n]\nYou can use the
pyproject.toml hatch.tomlonly-includeoption to prevent directory traversal starting at the project root and only select specific relative paths to directories or files. Using this option ignores any definedincludepatterns.[tool.hatch.build.targets.sdist]\nonly-include = [\"pkg\", \"tests/unit\"]\n
"},{"location":"config/build/#packages","title":"Packages","text":"[build.targets.sdist]\nonly-include = [\"pkg\", \"tests/unit\"]\nThe
packagesoption is semantically equivalent toonly-include(which takes precedence) except that the shipped path will be collapsed to only include the final component.So for example, if you want to ship a package
pyproject.toml hatch.tomlfoothat is stored in a directorysrcyou would do:[tool.hatch.build.targets.wheel]\npackages = [\"src/foo\"]\n
"},{"location":"config/build/#forced-inclusion","title":"Forced inclusion","text":"[build.targets.wheel]\npackages = [\"src/foo\"]\nThe
force-includeoption allows you to select specific files or directories from anywhere on the file system that should be included and map them to the desired relative distribution path.For example, if there was a directory alongside the project root named
pyproject.toml hatch.tomlartifactscontaining a file namedlib.soand a file namedlib.hin your home directory, you could ship both files in apkgdirectory with the following configuration:[tool.hatch.build.targets.wheel.force-include]\n\"../artifacts\" = \"pkg\"\n\"~/lib.h\" = \"pkg/lib.h\"\n[build.targets.wheel.force-include]\n\"../artifacts\" = \"pkg\"\n\"~/lib.h\" = \"pkg/lib.h\"\nNote
- Files must be mapped exactly to their desired paths, not to directories.
- The contents of directory sources are recursively included.
- To map directory contents directly to the root use
/(a forward slash). - Sources that do not exist will raise an error.
Warning
Files included using this option will overwrite any file path that was already included by other file selection options.
"},{"location":"config/build/#default-file-selection","title":"Default file selection","text":"If no file selection options are provided, then what gets included is determined by each build target.
"},{"location":"config/build/#excluding-files-outside-packages","title":"Excluding files outside packages","text":"If you want to exclude non-artifact files that do not reside within a Python package, set
pyproject.toml hatch.tomlonly-packagestotrue:[tool.hatch.build.targets.wheel]\nonly-packages = true\n
"},{"location":"config/build/#rewriting-paths","title":"Rewriting paths","text":"[build.targets.wheel]\nonly-packages = true\nYou can rewrite relative paths to directories with the
pyproject.toml hatch.tomlsourcesoption. For example, the following configuration:[tool.hatch.build.targets.wheel.sources]\n\"src/foo\" = \"bar\"\n[build.targets.wheel.sources]\n\"src/foo\" = \"bar\"\nwould distribute the file
src/foo/file.extasbar/file.ext.If you want to remove path prefixes entirely, rather than setting each to an empty string, you can define
pyproject.toml hatch.tomlsourcesas an array:[tool.hatch.build.targets.wheel]\nsources = [\"src\"]\n[build.targets.wheel]\nsources = [\"src\"]\nIf you want to add a prefix to paths, you can use an empty string. For example, the following configuration:
pyproject.toml hatch.toml[tool.hatch.build.targets.wheel.sources]\n\"\" = \"foo\"\n[build.targets.wheel.sources]\n\"\" = \"foo\"\nwould distribute the file
bar/file.extasfoo/bar/file.ext.The packages option itself relies on sources. Defining
pyproject.toml hatch.tomlpackages = [\"src/foo\"]for thewheeltarget is equivalent to the following:[tool.hatch.build.targets.wheel]\nonly-include = [\"src/foo\"]\nsources = [\"src\"]\n
"},{"location":"config/build/#performance","title":"Performance","text":"[build.targets.wheel]\nonly-include = [\"src/foo\"]\nsources = [\"src\"]\nAll encountered directories are traversed by default. To skip non-artifact directories that are excluded, set
pyproject.toml hatch.tomlskip-excluded-dirstotrue:[tool.hatch.build]\nskip-excluded-dirs = true\n[build]\nskip-excluded-dirs = true\nWarning
This may result in not shipping desired files. For example, if you want to include the file
"},{"location":"config/build/#reproducible-builds","title":"Reproducible builds","text":"a/b/c.txtbut your VCS ignoresa/b, the filec.txtwill not be seen because its parent directory will not be entered. In such cases you can use theforce-includeoption.By default, build targets will build in a reproducible manner provided that they support that behavior. To disable this, set
pyproject.toml hatch.tomlreproducibletofalse:[tool.hatch.build]\nreproducible = false\n[build]\nreproducible = false\nWhen enabled, the SOURCE_DATE_EPOCH environment variable will be used for all build timestamps. If not set, then Hatch will use an unchanging default value.
"},{"location":"config/build/#output-directory","title":"Output directory","text":"When the output directory is not provided to the
pyproject.toml hatch.tomlbuildcommand, thedistdirectory will be used by default. You can change the default to a different directory using a relative or absolute path like so:[tool.hatch.build]\ndirectory = \"<PATH>\"\n
"},{"location":"config/build/#dev-mode","title":"Dev mode","text":"[build]\ndirectory = \"<PATH>\"\nBy default for dev mode environment installations or editable installs, the
wheeltarget will determine which directories should be added to Python's search path based on the selected files.If you want to override this detection or perhaps instruct other build targets as well, you can use the
pyproject.toml hatch.tomldev-mode-dirsoption:[tool.hatch.build]\ndev-mode-dirs = [\".\"]\n[build]\ndev-mode-dirs = [\".\"]\nIf you don't want to add entire directories to Python's search path, you can enable a more targeted mechanism with the mutually exclusive
pyproject.toml hatch.tomldev-mode-exactoption:[tool.hatch.build]\ndev-mode-exact = true\n[build]\ndev-mode-exact = true\nWarning
The
"},{"location":"config/build/#build-targets","title":"Build targets","text":"dev-mode-exactmechanism is not supported by static analysis tools & IDEs, therefore functionality such as autocompletion is unlikely to work.A build target can be provided by any builder plugin. There are three built-in build targets: wheel, sdist, and custom.
"},{"location":"config/build/#dependencies","title":"Dependencies","text":"You can specify additional dependencies that will be installed in each build environment, such as for third party builders:
pyproject.toml hatch.toml[tool.hatch.build.targets.your-target-name]\ndependencies = [\n \"your-builder-plugin\"\n]\n[build.targets.your-target-name]\ndependencies = [\n \"your-builder-plugin\"\n]\nYou can also declare dependence on the project's runtime dependencies with the
pyproject.toml hatch.tomlrequire-runtime-dependenciesoption:[tool.hatch.build.targets.your-target-name]\nrequire-runtime-dependencies = true\n[build.targets.your-target-name]\nrequire-runtime-dependencies = true\nAdditionally, you may declare dependence on specific runtime features of the project with the
pyproject.toml hatch.tomlrequire-runtime-featuresoption:[tool.hatch.build.targets.your-target-name]\nrequire-runtime-features = [\n \"feature1\",\n \"feature2\",\n]\n
"},{"location":"config/build/#versions","title":"Versions","text":"[build.targets.your-target-name]\nrequire-runtime-features = [\n \"feature1\",\n \"feature2\",\n]\nIf a build target supports multiple build strategies or if there are major changes over time, you can specify exactly which versions you want to build using the
pyproject.toml hatch.tomlversionsoption:[tool.hatch.build.targets.<TARGET_NAME>]\nversions = [\n \"v1\",\n \"beta-feature\",\n]\n[build.targets.<TARGET_NAME>]\nversions = [\n \"v1\",\n \"beta-feature\",\n]\nSee the wheel target for a real world example.
"},{"location":"config/build/#build-hooks","title":"Build hooks","text":"A build hook defines code that will be executed at various stages of the build process and can be provided by any build hook plugin. There is one built-in build hook: custom.
Build hooks can be applied either globally:
pyproject.toml hatch.toml[tool.hatch.build.hooks.<HOOK_NAME>]\n[build.hooks.<HOOK_NAME>]\nor to specific build targets:
pyproject.toml hatch.toml[tool.hatch.build.targets.<TARGET_NAME>.hooks.<HOOK_NAME>]\n
"},{"location":"config/build/#dependencies_1","title":"Dependencies","text":"[build.targets.<TARGET_NAME>.hooks.<HOOK_NAME>]\nYou can specify additional dependencies that will be installed in each build environment, such as for third party build hooks:
pyproject.toml hatch.toml[tool.hatch.build.hooks.your-hook-name]\ndependencies = [\n \"your-build-hook-plugin\"\n]\n[build.hooks.your-hook-name]\ndependencies = [\n \"your-build-hook-plugin\"\n]\nYou can also declare dependence on the project's runtime dependencies with the
pyproject.toml hatch.tomlrequire-runtime-dependenciesoption:[tool.hatch.build.hooks.your-hook-name]\nrequire-runtime-dependencies = true\n[build.hooks.your-hook-name]\nrequire-runtime-dependencies = true\nAdditionally, you may declare dependence on specific runtime features of the project with the
pyproject.toml hatch.tomlrequire-runtime-featuresoption:[tool.hatch.build.hooks.your-hook-name]\nrequire-runtime-features = [\n \"feature1\",\n \"feature2\",\n]\n
"},{"location":"config/build/#order-of-execution","title":"Order of execution","text":"[build.hooks.your-hook-name]\nrequire-runtime-features = [\n \"feature1\",\n \"feature2\",\n]\nFor each build target, build hooks execute in the order in which they are defined, starting with global hooks.
As an example, for the following configuration:
pyproject.toml hatch.toml[tool.hatch.build.targets.foo.hooks.hook2]\n\n[tool.hatch.build.hooks.hook3]\n[tool.hatch.build.hooks.hook1]\n[build.targets.foo.hooks.hook2]\n\n[build.hooks.hook3]\n[build.hooks.hook1]\nWhen target
"},{"location":"config/build/#conditional-execution","title":"Conditional execution","text":"foois built, build hookhook3will be executed first, followed byhook1, and then finallyhook2.If you want to disable a build hook by default and control its use by environment variables, you can do so by setting the
pyproject.toml hatch.tomlenable-by-defaultoption tofalse:[tool.hatch.build.hooks.<HOOK_NAME>]\nenable-by-default = false\n
"},{"location":"config/build/#environment-variables","title":"Environment variables","text":"Variable Default Description[build.hooks.<HOOK_NAME>]\nenable-by-default = false\nHATCH_BUILD_CLEANfalseWhether or not existing artifacts should first be removedHATCH_BUILD_CLEAN_HOOKS_AFTERfalseWhether or not build hook artifacts should be removed after each buildHATCH_BUILD_HOOKS_ONLYfalseWhether or not to only execute build hooksHATCH_BUILD_NO_HOOKSfalseWhether or not to disable all build hooks; this takes precedence over other optionsHATCH_BUILD_HOOKS_ENABLEfalseWhether or not to enable all build hooksHATCH_BUILD_HOOK_ENABLE_<HOOK_NAME>falseWhether or not to enable the build hook named<HOOK_NAME>HATCH_BUILD_LOCATIONdistThe location with which to build the targets; only used by thebuildcommand-
Support for PEP 517 and PEP 660 guarantees interoperability with other build tools.\u00a0\u21a9
You can populate configuration with the values of certain supported fields using the syntax of Python's format strings. Each field interprets the modifier part after the colon differently, if at all.
"},{"location":"config/context/#global-fields","title":"Global fields","text":"Any configuration that declares support for context formatting will always support these fields.
"},{"location":"config/context/#paths","title":"Paths","text":"Field DescriptionrootThe root project directoryhomeThe user's home directoryAll paths support the following modifiers:
Modifier DescriptionuriThe normalized absolute URI path prefixed byfile:realThe path with all symbolic links resolvedparentThe parent of the preceding pathTip
The
pyproject.toml hatch.tomlparentmodifier can be chained and may be combined with either theuriorrealmodifier, with the latter placed at the end. For example:[tool.hatch.envs.test]\ndependencies = [\n \"example-project @ {root:parent:parent:uri}/example-project\",\n]\n
"},{"location":"config/context/#system-separators","title":"System separators","text":"Field Description[envs.test]\ndependencies = [\n \"example-project @ {root:parent:parent:uri}/example-project\",\n]\n/\\on Windows,/otherwise;;on Windows,:otherwise"},{"location":"config/context/#environment-variables","title":"Environment variables","text":"The
"},{"location":"config/context/#field-nesting","title":"Field nesting","text":"envfield and its modifier allow you to select the value of an environment variable. If the environment variable is not set, you must specify a default value as an additional modifier e.g.{env:PATH:DEFAULT}.You can insert fields within others. For example, if you wanted a script that displays the value of the environment variable
pyproject.toml hatch.tomlFOO, with a fallback to the environment variableBAR, with its own fallback to the user's home directory, you could do the following:[tool.hatch.envs.test.scripts]\ndisplay = \"echo {env:FOO:{env:BAR:{home}}}\"\n
"},{"location":"config/dependency/","title":"Dependency configuration","text":"[envs.test.scripts]\ndisplay = \"echo {env:FOO:{env:BAR:{home}}}\"\nProject dependencies are defined with PEP 508 strings using optional PEP 440 version specifiers.
"},{"location":"config/dependency/#version-specifiers","title":"Version specifiers","text":"A version specifier consists of a series of version clauses, separated by commas. For example:
pyproject.toml[project]\n...\ndependencies = [\n \"cryptography\",\n \"click>=7, <9, != 8.0.0\",\n \"python-dateutil==2.8.*\",\n \"numpy~=1.21.4\",\n]\nThe comma is equivalent to a logical
"},{"location":"config/dependency/#operators","title":"Operators","text":"Operators FunctionANDoperator: a candidate version must match all given version clauses in order to match the specifier as a whole.~=Compatible release==Version matching!=Version exclusion<=,>=Inclusive ordered comparison<,>Exclusive ordered comparison===Arbitrary equality"},{"location":"config/dependency/#version-matching","title":"Version matching","text":"A version matching clause includes the version matching operator
==and a version identifier.By default, the version matching operator is based on a strict equality comparison: the specified version must be exactly the same as the requested version.
Clause Allowed versions==11.0.0==1.21.2.0Prefix matching may be requested instead of strict comparison, by appending a trailing
Clause Allowed versions.*to the version identifier in the version matching clause. This means that additional trailing segments will be ignored when determining whether or not a version identifier matches the clause.==1.*>=1.0.0, <2.0.0==1.2.*>=1.2.0, <1.3.0"},{"location":"config/dependency/#compatible-release","title":"Compatible release","text":"A compatible release clause consists of the compatible release operator
~=and a version identifier. It matches any candidate version that is expected to be compatible with the specified version.For a given release identifier
V.N, the compatible release clause is approximately equivalent to the following pair of comparison clauses:>= V.N, == V.*\nThis operator cannot be used with a single segment version number such as
Clause Allowed versions~=1.~=1.2>=1.2.0, <2.0.0~=1.2.3>=1.2.3, <1.3.0"},{"location":"config/dependency/#version-exclusion","title":"Version exclusion","text":"A version exclusion clause includes the version exclusion operator
!=and a version identifier.The allowed version identifiers and comparison semantics are the same as those of the Version matching operator, except that the sense of any match is inverted.
"},{"location":"config/dependency/#ordered-comparison","title":"Ordered comparison","text":"Inclusive comparisons allow for the version identifier part of clauses whereas exclusive comparisons do not. For example,
>=1.2allows for version1.2.0while>1.2does not.Unlike the inclusive ordered comparisons
"},{"location":"config/dependency/#arbitrary-equality","title":"Arbitrary equality","text":"<=and>=, the exclusive ordered comparisons<and>specifically exclude pre-releases, post-releases, and local versions of the specified version.Though heavily discouraged, arbitrary equality comparisons allow for simple string matching without any version semantics, for example
"},{"location":"config/dependency/#environment-markers","title":"Environment markers","text":"===foobar.Environment markers allow for dependencies to only be installed when certain conditions are met.
For example, if you need to install the latest version of
cryptographythat is available for a given Python major version you could define the following:cryptography==3.3.2; python_version < \"3\"\ncryptography>=35.0; python_version > \"3\"\nAlternatively, if you only need it on Python 3 when running on Windows you could do:
cryptography; python_version ~= \"3.0\" and platform_system == \"Windows\"\nThe available environment markers are as follows.
Marker Python equivalent Examplesos_nameimport osos.name- posix
- java
sys_platformimport syssys.platform- linux
- win32
- darwin
platform_machineimport platformplatform.machine()- x86_64
platform_python_implementationimport platformplatform.python_implementation()- CPython
- Jython
platform_releaseimport platformplatform.release()- 1.8.0_51
- 3.14.1-x86_64-linode39
platform_systemimport platformplatform.system()- Linux
- Windows
- Darwin
platform_versionimport platformplatform.version()- 10.0.19041
- #1 SMP Fri Apr 2 22:23:49 UTC 2021
python_versionimport platform'.'.join(platform.python_version_tuple()[:2])- 2.7
- 3.10
python_full_versionimport platformplatform.python_version()- 2.7.18
- 3.11.0b1
implementation_nameimport syssys.implementation.name- cpython
implementation_versionSee here- 2.7.18
- 3.11.0b1
You can select groups of optional dependencies to install using the extras syntax. For example, if a dependency named
pyproject.tomlfoodefined the following:[project.optional-dependencies]\ncrypto = [\n \"PyJWT\",\n \"cryptography\",\n]\nfastjson = [\n \"orjson\",\n]\ncli = [\n \"prompt-toolkit\",\n \"colorama; platform_system == 'Windows'\",\n]\nYou can select the
cliandcryptofeatures like so:foo[cli,crypto]==1.*\nNote that the features come immediately after the package name, before any version specifiers.
"},{"location":"config/dependency/#self-referential","title":"Self-referential","text":"Feature groups can self-referentially extend others. For example, for a project called
pyproject.tomlawesome-project, thedevfeature group in the followingpyproject.tomlfile would select everything in thecryptofeature group, plusblack:
"},{"location":"config/dependency/#direct-references","title":"Direct references","text":"[project]\nname = \"awesome-project\"\n\n[project.optional-dependencies]\ncrypto = [\n \"PyJWT\",\n \"cryptography\",\n]\ndev = [\n \"awesome-project[crypto]\",\n \"black\",\n]\nInstead of using normal version specifiers and fetching packages from an index like PyPI, you can define exact sources using direct references with an explicit URI.
Direct references are usually not meant to be used for dependencies of a published project but rather are used for defining dependencies for an environment.
All direct reference types are prefixed by the package name like:
"},{"location":"config/dependency/#version-control-systems","title":"Version control systems","text":"<NAME> @ <REFERENCE>\nVarious version control systems (VCS) are supported as long as the associated executable is available along your
PATH.VCS direct references are defined using one of the following formats:
<NAME> @ <SCHEME>://<PATH>\n<NAME> @ <SCHEME>://<PATH>@<REVISION>\nYou may also append a
#subdirectory=<PATH>component for specifying the relative path to the Python package when it is not located at the root e.g.#subdirectory=lib/foo.For more information, refer to this.
"},{"location":"config/dependency/#supported-vcs","title":"Supported VCS","text":"GitMercurialSubversionBazaar Executable Schemes Revisions Examplegitgit+filegit+httpsgit+sshgit+httpgit+gitgit
- Commit hash
- Tag name
- Branch name
proj @ git+https://github.com/org/proj.git@v1Executable Schemes Revisions Examplehghg+filehg+httpshg+sshhg+httphg+static-http
- Revision hash
- Revision number
- Tag name
- Branch name
proj @ hg+file:///path/to/proj@v1Executable Schemes Revisions Examplesvnsvn+httpssvn+sshsvn+httpsvn+svnsvn
- Revision number
proj @ svn+file:///path/to/projExecutable Schemes Revisions Examplebzrbzr+httpsbzr+sshbzr+sftpbzr+lpbzr+httpbzr+ftp
- Revision number
- Tag name
proj @ bzr+lp:proj@v1"},{"location":"config/dependency/#local","title":"Local","text":"You can install local packages with the
filescheme in the following format:<NAME> @ file://<HOST>/<PATH>\nThe
<HOST>is only used on Windows systems, where it can refer to a network share. If omitted it is assumed to belocalhostand the third slash must still be present.The
Type Unix Windows Source archive<PATH>can refer to a source archive, a wheel, or a directory containing a Python package.proj @ file:///path/to/pkg.tar.gzproj @ file:///c:/path/to/pkg.tar.gzWheelproj @ file:///path/to/pkg.whlproj @ file:///c:/path/to/pkg.whlDirectoryproj @ file:///path/to/pkgproj @ file:///c:/path/to/pkgTip
You may also specify paths relative to your project's root directory on all platforms by using context formatting:
"},{"location":"config/dependency/#remote","title":"Remote","text":"<NAME> @ {root:uri}/pkg_inside_project\n<NAME> @ {root:parent:uri}/pkg_alongside_project\nYou can install source archives and wheels by simply referring to a URL:
black @ https://github.com/psf/black/archive/refs/tags/21.10b0.zip\npytorch @ https://download.pytorch.org/whl/cu102/torch-1.10.0%2Bcu102-cp39-cp39-linux_x86_64.whl\nAn expected hash value may be specified by appending a
#<HASH_ALGORITHM>=<EXPECTED_HASH>component:requests @ https://github.com/psf/requests/archive/refs/tags/v2.26.0.zip#sha256=eb729a757f01c10546ebd179ae2aec852dd0d7f8ada2328ccf4558909d859985\nIf the hash differs from the expected hash, the installation will fail.
It is recommended that only hashes which are unconditionally provided by the latest version of the standard library's hashlib module be used for hashes. As of Python 3.10, that list consists of:
md5sha1sha224sha256sha384sha512blake2bblake2s
The following is an example that uses features and environment markers:
pkg[feature1,feature2] @ <REFERENCE> ; python_version < \"3.7\"\nNote that the space before the semicolon is required.
"},{"location":"config/hatch/","title":"Hatch configuration","text":"Configuration for Hatch itself is stored in a
Platform Path macOSconfig.tomlfile located by default in one of the following platform-specific directories.~/Library/Application Support/hatchWindows%USERPROFILE%\\AppData\\Local\\hatchUnix$XDG_CONFIG_HOME/hatch(the XDG_CONFIG_HOME environment variable default is~/.config)You can select a custom path to the file using the
--configroot option or by setting theHATCH_CONFIGenvironment variable.The file can be managed by the
"},{"location":"config/hatch/#mode","title":"Mode","text":"configcommand group.The
"},{"location":"config/hatch/#local","title":"Local","text":"config.tomlmodekey controls how Hatch selects the project to work on.mode = \"local\"\nBy default, Hatch will look for a
"},{"location":"config/hatch/#project","title":"Project","text":"config.tomlpyproject.tomlfile in the current working directory and any parent directories. The directory storing the first found file will be considered the project root.mode = \"project\"\nproject = \"proj1\"\n\n[projects]\nproj1 = \"/path/to/project1\"\nproj2 = {\"location\": \"/path/to/project2\"}\n\n[dirs]\nproject = [\"/path/to/monorepo1\", \"/path/to/monorepo2\"]\nIn this mode, Hatch will only work on the selected
project. The project is located using multiple heuristics:- If the project is defined in the
projectstable then it must be a string, or an inline table with alocationkey, that is the full path to the project. - If the project matches a subdirectory in any of the directories listed in
dirs.project, then that will be used as the project root.
An error will occur if the project cannot be found.
You can use the
config setcommand to change the project you are working on:$ hatch config set project proj2\nNew setting:\nproject = \"proj2\"\nThe project can be selected on a per-command basis with the
"},{"location":"config/hatch/#aware","title":"Aware","text":"config.toml-p/--project(environment variableHATCH_PROJECT) root option.mode = \"aware\"\nThis is essentially the
"},{"location":"config/hatch/#shell","title":"Shell","text":"localmode with a fallback to theprojectmode.You can control the shell used to enter environments with the
shellkey.If defined as a string, it must be the name of one of the supported shells and be available along your
config.tomlPATH.shell = \"fish\"\nIf the executable name of your shell differs from the supported name, you can define the
config.tomlshellas a table withnameandpathkeys.[shell]\nname = \"bash\"\npath = \"/bin/ash\"\nYou can change the default arguments used to spawn most shells with the
config.tomlargskey. The default for such supported shells is usually[\"-i\"].
"},{"location":"config/hatch/#supported","title":"Supported","text":"Shell Name Arguments macOS Windows Unix Almquist shell[shell]\nname = \"bash\"\nargs = [\"--login\"]\nash[\"-i\"]Bashbash[\"-i\"]Command PromptcmdC shellcsh[\"-i\"]fishfish[\"-i\"]Nushellnu[]PowerShellpwsh,powershelltcshtcsh[\"-i\"]xonshxonsh[\"-i\"]Z shellzsh[\"-i\"]"},{"location":"config/hatch/#default","title":"Default","text":"Hatch will attempt to use the current shell based on parent processes. If the shell cannot be determined, then on Windows systems Hatch will use the
"},{"location":"config/hatch/#directories","title":"Directories","text":""},{"location":"config/hatch/#data","title":"Data","text":"config.tomlSHELLenvironment variable, if present, followed by theCOMSPECenvironment variable, defaulting tocmd. On all other platforms only theSHELLenvironment variable will be used, defaulting tobash.[dirs]\ndata = \"...\"\nThis is the directory that is used to persist data. By default it is set to one of the following platform-specific directories.
Platform Path macOS~/Library/Application Support/hatchWindows%USERPROFILE%\\AppData\\Local\\hatchUnix$XDG_DATA_HOME/hatch(the XDG_DATA_HOME environment variable default is~/.local/share)You can select a custom path to the directory using the
"},{"location":"config/hatch/#cache","title":"Cache","text":"config.toml--data-dirroot option or by setting theHATCH_DATA_DIRenvironment variable.[dirs]\ncache = \"...\"\nThis is the directory that is used to cache data. By default it is set to one of the following platform-specific directories.
Platform Path macOS~/Library/Caches/hatchWindows%USERPROFILE%\\AppData\\Local\\hatch\\CacheUnix$XDG_CACHE_HOME/hatch(the XDG_CACHE_HOME environment variable default is~/.cache)You can select a custom path to the directory using the
"},{"location":"config/hatch/#environments","title":"Environments","text":"config.toml--cache-dirroot option or by setting theHATCH_CACHE_DIRenvironment variable.[dirs.env]\n<ENV_TYPE> = \"...\"\nThis determines where to store environments, with every key being the type of environment and the value being the desired storage location.
For example, if you wanted to store virtual environments in a
config.toml.virtualenvsdirectory within your home directory, you could specify the following:[dirs.env]\nvirtual = \"~/.virtualenvs\"\nAny environment variables are also expanded.
If the path is not absolute, then it will be relative to the project root. So if you wanted to use a directory named
config.toml.hatchin each project directory, you could do:[dirs.env]\nvirtual = \".hatch\"\nAny type of environment that is not explicitly defined will default to
"},{"location":"config/hatch/#python-installations","title":"Python installations","text":"config.toml<DATA_DIR>/env/<ENV_TYPE>.[dirs]\npython = \"...\"\nThis determines where to install specific versions of Python.
The following values have special meanings:
Value Pathisolated(default)<DATA_DIR>/pythons"},{"location":"config/hatch/#terminal","title":"Terminal","text":"You can configure how all output is displayed using the
config.tomlterminal.stylestable. These settings are also applied to all plugins.[terminal.styles]\nerror = \"...\"\n...\nCross-platform terminal capabilities are provided by Rich.
"},{"location":"config/hatch/#output-levels","title":"Output levels","text":"The levels of output are as follows. Note that the verbosity indicates the minimum level at which the output is displayed.
Level Default Verbosity Descriptiondebugbold1 - 3 Messages that are not useful for most user experienceserrorbold red-2 Messages indicating some unrecoverable errorinfobold0 Messages conveying basic informationsuccessbold cyan0 Messages indicating some positive outcomewaitingbold magenta0 Messages shown before potentially time consuming operationswarningbold yellow-1 Messages conveying important informationSee the documentation and color reference for guidance on valid values.
"},{"location":"config/hatch/#spinner","title":"Spinner","text":"You can select the sequence used for waiting animations with the
config.tomlspinneroption.
"},{"location":"config/metadata/","title":"Configuring project metadata","text":"[terminal.styles]\nspinner = \"...\"\nProject metadata is stored in a
"},{"location":"config/metadata/#name","title":"Name (required)","text":"pyproject.tomlfile located at the root of a project's tree and is based entirely on the standard.The name of the project.
pyproject.toml
"},{"location":"config/metadata/#version","title":"Version (required)","text":"pyproject.toml DynamicStatic[project]\nname = \"your-app\"\nSee the dedicated versioning section.
[project]\n...\ndynamic = [\"version\"]\n\n[tool.hatch.version]\npath = \"...\"\n
"},{"location":"config/metadata/#description","title":"Description","text":"[project]\n...\nversion = \"0.0.1\"\nA brief summary of the project.
pyproject.toml
"},{"location":"config/metadata/#readme","title":"Readme","text":"[project]\n...\ndescription = '...'\nThe full description of the project.
pyproject.toml SimpleComplexThe file extension must be
.md,.rst, or.txt.[project]\n...\nreadme = \"README.md\"\nThe
FileTextcontent-typefield must be set totext/markdown,text/x-rst, ortext/plain.A
charsetfield may also be set to instruct which encoding to use for reading the file, defaulting toutf-8.[project]\n...\nreadme = {\"file\" = \"README.md\", \"content-type\" = \"text/markdown\"}\nThe
content-typefield must be set totext/markdownortext/x-rst.[project]\n...\nreadme = {\"text\" = \"...\", \"content-type\" = \"text/markdown\"}\nNote
If this is defined as a file, then it will always be included in source distributions for consistent builds.
"},{"location":"config/metadata/#python-support","title":"Python support","text":"The Python version requirements of the project.
pyproject.toml
"},{"location":"config/metadata/#license","title":"License","text":"[project]\n...\nrequires-python = \">=3.8\"\nFor more information, see PEP 639.
pyproject.toml SPDX expressionFiles
PathsGlobs[project]\n...\nlicense = \"Apache-2.0 OR MIT\"\n[project]\n...\nlicense-files = { paths = [\"LICENSE.txt\"] }\n
"},{"location":"config/metadata/#ownership","title":"Ownership","text":"[project]\n...\nlicense-files = { globs = [\"LICENSES/*\"] }\nThe people or organizations considered to be the
pyproject.tomlauthorsormaintainersof the project. The exact meaning is open to interpretation; it may list the original or primary authors, current maintainers, or owners of the package. If the values are the same, prefer only the use of theauthorsfield.
"},{"location":"config/metadata/#keywords","title":"Keywords","text":"[project]\n...\nauthors = [\n { name = \"...\", email = \"...\" },\n]\nmaintainers = [\n { name = \"...\", email = \"...\" },\n]\nThe keywords used to assist in the discovery of the project.
pyproject.toml
"},{"location":"config/metadata/#classifiers","title":"Classifiers","text":"[project]\n...\nkeywords = [\n \"...\",\n]\nThe trove classifiers that apply to the project.
pyproject.toml
"},{"location":"config/metadata/#urls","title":"URLs","text":"[project]\n...\nclassifiers = [\n \"...\",\n]\nA table of URLs where the key is the URL label and the value is the URL itself.
pyproject.toml
"},{"location":"config/metadata/#dependencies","title":"Dependencies","text":"[project.urls]\nDocumentation = \"...\"\n\"Source code\" = \"...\"\nSee the dependency specification page for more information.
Entries support context formatting and disallow direct references by default.
"},{"location":"config/metadata/#required","title":"Required","text":"pyproject.toml
"},{"location":"config/metadata/#optional","title":"Optional","text":"pyproject.toml[project]\n...\ndependencies = [\n \"...\",\n]\n
"},{"location":"config/metadata/#entry-points","title":"Entry points","text":"[project.optional-dependencies]\noption1 = [\n \"...\",\n]\noption2 = [\n \"...\",\n]\nEntry points are a mechanism for the project to advertise components it provides to be discovered and used by other code.
"},{"location":"config/metadata/#cli","title":"CLI","text":"After installing projects that define CLI scripts, each key will be available along your
pyproject.tomlPATHas a command that will call its associated object.[project.scripts]\ncli-name = \"pkg.subpkg:func\"\nUsing the above example, running
cli-namewould essentially execute the following Python script:
"},{"location":"config/metadata/#gui","title":"GUI","text":"import sys\n\nfrom pkg.subpkg import func\n\nsys.exit(func())\nGUI scripts are exactly the same as CLI scripts except on Windows, where they are handled specially so that they can be started without a console.
pyproject.toml
"},{"location":"config/metadata/#plugins","title":"Plugins","text":"pyproject.toml[project.gui-scripts]\ngui-name = \"pkg.subpkg:func\"\n
"},{"location":"config/metadata/#dynamic","title":"Dynamic","text":"[project.entry-points.plugin-namespace]\nplugin-name1 = \"pkg.subpkg1\"\nplugin-name2 = \"pkg.subpkg2:func\"\nIf any metadata fields are set dynamically, like the
pyproject.tomlversionmay be, then they must be listed here.
"},{"location":"config/metadata/#metadata-options","title":"Metadata options","text":""},{"location":"config/metadata/#allowing-direct-references","title":"Allowing direct references","text":"[project]\n...\ndynamic = [\n \"...\",\n]\nBy default, dependencies are not allowed to define direct references. To disable this check, set
pyproject.toml hatch.tomlallow-direct-referencestotrue:[tool.hatch.metadata]\nallow-direct-references = true\n
"},{"location":"config/metadata/#allowing-ambiguous-features","title":"Allowing ambiguous features","text":"[metadata]\nallow-direct-references = true\nBy default, names of optional dependencies are normalized to prevent ambiguity. To disable this normalization, set
pyproject.toml hatch.tomlallow-ambiguous-featurestotrue:[tool.hatch.metadata]\nallow-ambiguous-features = true\n[metadata]\nallow-ambiguous-features = true\nDeprecated
This option temporarily exists to provide better interoperability with tools that do not yet support PEP 685 and will be removed in the first minor release after Jan 1, 2024.
"},{"location":"config/project-templates/","title":"Project templates","text":"You can control how new projects are created by the new command using Hatch's config file.
"},{"location":"config/project-templates/#author","title":"Author","text":"config.toml
"},{"location":"config/project-templates/#licenses","title":"Licenses","text":"config.toml[template]\nname = \"...\"\nemail = \"...\"\n[template.licenses]\nheaders = true\ndefault = [\n \"MIT\",\n]\nThe list of licenses should be composed of SPDX identifiers. If multiple licenses are specified, then they will be placed in a LICENSES directory.
"},{"location":"config/project-templates/#options","title":"Options","text":""},{"location":"config/project-templates/#tests","title":"Tests","text":"This adds a
config.tomltestsdirectory with environments for testing and linting.
"},{"location":"config/project-templates/#ci","title":"CI","text":"[template.plugins.default]\ntests = true\nThis adds a GitHub Actions workflow that runs tests on all platforms using modern versions of Python.
config.toml
"},{"location":"config/project-templates/#src-layout","title":"[template.plugins.default]\nci = false\nsrclayout","text":"See this blog post.
config.toml
"},{"location":"config/project-templates/#feature-flags","title":"Feature flags","text":""},{"location":"config/project-templates/#command-line-interface","title":"Command line interface","text":"[template.plugins.default]\nsrc-layout = true\nThe
"},{"location":"config/environment/advanced/","title":"Advanced environment configuration","text":""},{"location":"config/environment/advanced/#context-formatting","title":"Context formatting","text":"--cliflag adds a CLI backed by Click that can also be invoked withpython -m <PKG_NAME>.All environments support the following extra context formatting fields:
Field Descriptionenv_nameThe name of the environmentenv_typeThe type of environmentmatrixIts modifier selects the value of that matrix variable. If the environment is not part of a matrix or was not generated with the variable, you must specify a default value as an additional modifier e.g.{matrix:version:v1.0.0}.verbosityThe integer verbosity value of Hatch. Aflagmodifier is supported that will render the value as a CLI flag e.g.-2becomes-qq,1becomes-v, and0becomes an empty string. An additional flag integer modifier may be used to adjust the verbosity level. For example, if you wanted to make a command quiet by default, you could use{verbosity:flag:-1}within the command.argsFor executed commands only, any extra command line arguments with an optional default modifier if none were provided"},{"location":"config/environment/advanced/#matrix","title":"Matrix","text":"Environments can define a series of matrices with the
pyproject.toml hatch.tomlmatrixoption:[tool.hatch.envs.test]\ndependencies = [\n \"pytest\"\n]\n\n[[tool.hatch.envs.test.matrix]]\npython = [\"3.10\", \"3.11\"]\nversion = [\"42\", \"3.14\"]\n\n[[tool.hatch.envs.test.matrix]]\npython = [\"3.11\", \"3.12\"]\nversion = [\"9000\"]\nfeature = [\"foo\", \"bar\"]\n[envs.test]\ndependencies = [\n \"pytest\"\n]\n\n[[envs.test.matrix]]\npython = [\"3.10\", \"3.11\"]\nversion = [\"42\", \"3.14\"]\n\n[[envs.test.matrix]]\npython = [\"3.11\", \"3.12\"]\nversion = [\"9000\"]\nfeature = [\"foo\", \"bar\"]\nDoing so will result in the product of each variable combination being its own environment.
"},{"location":"config/environment/advanced/#naming","title":"Naming","text":"The name of the generated environments will be the variable values of each combination separated by hyphens, altogether prefixed by
pyproject.toml hatch.toml<ENV_NAME>.. For example, the following configuration:[[tool.hatch.envs.test.matrix]]\nversion = [\"42\"]\nfeature = [\"foo\", \"bar\"]\n[[envs.test.matrix]]\nversion = [\"42\"]\nfeature = [\"foo\", \"bar\"]\nwould indicate the following unique environments:
test.42-foo\ntest.42-bar\nThe exceptions to this format are described below.
"},{"location":"config/environment/advanced/#python-variables","title":"Python variables","text":"If the variables
pyproject.toml hatch.tomlpyorpythonare specified, then they will rank first in the product result and will be prefixed bypyif the value is not. For example, the following configuration:[[tool.hatch.envs.test.matrix]]\nversion = [\"42\"]\npython = [\"3.9\", \"pypy3\"]\n[[envs.test.matrix]]\nversion = [\"42\"]\npython = [\"3.9\", \"pypy3\"]\nwould generate the following environments:
test.py3.9-42\ntest.pypy3-42\nNote
The value of this variable sets the Python version.
"},{"location":"config/environment/advanced/#name-formatting","title":"Name formatting","text":"You can set the
pyproject.toml hatch.tomlmatrix-name-formatoption to modify how each variable part is formatted which recognizes the placeholders{variable}and{value}. For example, the following configuration:[tool.hatch.envs.test]\nmatrix-name-format = \"{variable}_{value}\"\n\n[[tool.hatch.envs.test.matrix]]\nversion = [\"42\"]\nfeature = [\"foo\", \"bar\"]\n[envs.test]\nmatrix-name-format = \"{variable}_{value}\"\n\n[[envs.test.matrix]]\nversion = [\"42\"]\nfeature = [\"foo\", \"bar\"]\nwould produce the following environments:
test.version_42-feature_foo\ntest.version_42-feature_bar\nBy default this option is set to
"},{"location":"config/environment/advanced/#default-environment","title":"Default environment","text":"{value}.If the
"},{"location":"config/environment/advanced/#selection","title":"Selection","text":"defaultenvironment defines matrices, then the generated names will not be prefixed by the environment name. This can be useful for projects that only need a single series of matrices without any standalone environments.Rather than selecting a single generated environment, you can select the root environment to target all of them. For example, if you have the following configuration:
pyproject.toml hatch.toml[tool.hatch.envs.test]\ndependencies = [\n \"coverage[toml]\",\n \"pytest\",\n \"pytest-cov\",\n]\n\n[tool.hatch.envs.test.scripts]\ncov = 'pytest --cov-report=term-missing --cov-config=pyproject.toml --cov=pkg --cov=tests'\n\n[[tool.hatch.envs.test.matrix]]\npython = [\"3.11\", \"3.12\"]\nversion = [\"42\", \"3.14\"]\n[envs.test]\ndependencies = [\n \"coverage[toml]\",\n \"pytest\",\n \"pytest-cov\",\n]\n\n[envs.test.scripts]\ncov = 'pytest --cov-report=term-missing --cov-config=pyproject.toml --cov=pkg --cov=tests'\n\n[[envs.test.matrix]]\npython = [\"3.11\", \"3.12\"]\nversion = [\"42\", \"3.14\"]\nyou could then run your tests consecutively in all 4 environments with:
"},{"location":"config/environment/advanced/#option-overrides","title":"Option overrides","text":"hatch run test:cov\nYou can modify options based on the conditions of different sources like matrix variables with the
pyproject.toml hatch.tomloverridestable, using dotted key syntax for each declaration:[tool.hatch.envs.<ENV_NAME>.overrides]\n<SOURCE>.<CONDITION>.<OPTION> = <VALUE>\n[envs.<ENV_NAME>.overrides]\n<SOURCE>.<CONDITION>.<OPTION> = <VALUE>\nThe type of the selected option determines the types of values.
"},{"location":"config/environment/advanced/#platform-overrides","title":"Platform overrides","text":"Options can be modified based on the current platform using the
pyproject.toml hatch.tomlplatformsource.[tool.hatch.envs.test.overrides]\nplatform.windows.scripts = [\n 'run=pytest -m \"not io_uring\"',\n]\n[envs.test.overrides]\nplatform.windows.scripts = [\n 'run=pytest -m \"not io_uring\"',\n]\nThe following platforms are supported:
linuxwindowsmacos
Environment variables can modify options using the
pyproject.toml hatch.tomlenvsource.[tool.hatch.envs.test.overrides]\nenv.GITHUB_ACTIONS.dev-mode = { value = false, if = [\"true\"] }\n
"},{"location":"config/environment/advanced/#matrix-variable-overrides","title":"Matrix variable overrides","text":"[envs.test.overrides]\nenv.GITHUB_ACTIONS.dev-mode = { value = false, if = [\"true\"] }\nThe matrix variables used to generate each environment can be used to modify options within using the
pyproject.toml hatch.tomlmatrixsource.[tool.hatch.envs.test.overrides]\nmatrix.version.env-vars = \"PRODUCT_VERSION\"\nmatrix.auth.features = [\n { value = \"oauth\", if = [\"oauth2\"] },\n { value = \"kerberos\", if = [\"kerberos\"] },\n]\n\n[[tool.hatch.envs.test.matrix]]\npython = [\"3.11\", \"3.12\"]\nversion = [\"legacy\", \"latest\"]\nauth = [\"oauth2\", \"kerberos\", \"noauth\"]\n
"},{"location":"config/environment/advanced/#name-overrides","title":"Name overrides","text":"[envs.test.overrides]\nmatrix.version.env-vars = \"PRODUCT_VERSION\"\nmatrix.auth.features = [\n { value = \"oauth\", if = [\"oauth2\"] },\n { value = \"kerberos\", if = [\"kerberos\"] },\n]\n\n[[envs.test.matrix]]\npython = [\"3.11\", \"3.12\"]\nversion = [\"legacy\", \"latest\"]\nauth = [\"oauth2\", \"kerberos\", \"noauth\"]\nWhen a matrix is defined, the
pyproject.toml hatch.tomlnamesource can be used for regular expression matching on the generated name, minus the prefix for non-default environments.[tool.hatch.envs.test.overrides]\nname.\"^0\".env-vars = \"TESTING_UNSTABLE=true\"\n\n[[tool.hatch.envs.test.matrix]]\nversion = [\"0.1.0\", \"0.2.0\", \"1.0.0\"]\n
"},{"location":"config/environment/advanced/#types","title":"Types","text":"[envs.test.overrides]\nname.\"^0\".env-vars = \"TESTING_UNSTABLE=true\"\n\n[[envs.test.matrix]]\nversion = [\"0.1.0\", \"0.2.0\", \"1.0.0\"]\n-
Literal types like strings for the Python version or booleans for skipping installation can be set using the value itself, an inline table, or an array. For example:
pyproject.toml hatch.toml[tool.hatch.envs.test.overrides]\nmatrix.foo.python = \"3.10\"\nmatrix.bar.skip-install = { value = true, if = [\"...\"] }\nenv.CI.dev-mode = [\n { value = false, if = [\"...\"] },\n true,\n]\n[envs.test.overrides]\nmatrix.foo.python = \"3.10\"\nmatrix.bar.skip-install = { value = true, if = [\"...\"] }\nenv.CI.dev-mode = [\n { value = false, if = [\"...\"] },\n true,\n]\nFor arrays, the first allowed value will be used.
-
Array types like dependencies or commands can be appended to using an array of strings or inline tables. For example:
pyproject.toml hatch.toml[tool.hatch.envs.test.overrides]\nmatrix.foo.dependencies = [\n \"httpx\",\n { value = \"cryptography\" },\n]\n[envs.test.overrides]\nmatrix.foo.dependencies = [\n \"httpx\",\n { value = \"cryptography\" },\n]\n -
Mapping types like environment variables or scripts can have keys set using a string, or an array of strings or inline tables. For example:
pyproject.toml hatch.toml[tool.hatch.envs.test.overrides]\nmatrix.foo.env-vars = \"KEY=VALUE\"\nmatrix.bar.env-vars = [\n \"KEY1=VALUE1\",\n { key = \"KEY2\", value = \"VALUE2\" },\n]\n[envs.test.overrides]\nmatrix.foo.env-vars = \"KEY=VALUE\"\nmatrix.bar.env-vars = [\n \"KEY1=VALUE1\",\n { key = \"KEY2\", value = \"VALUE2\" },\n]\nIf the value is missing (no
=for strings, novaluekey for inline tables), then the value will be set to the value of the source condition.
Rather than supplementing the values within mapping types or array types, you can overwrite the option as a whole by prefixing the name with
pyproject.toml hatch.tomlset-:[tool.hatch.envs.test.overrides]\nmatrix.foo.set-platforms = [\"macos\", \"linux\"]\n[envs.test.overrides]\nmatrix.foo.set-platforms = [\"macos\", \"linux\"]\nWhen overwriting entire options or keys within mappings, override sources are applied in the following order:
- platform
- environment variables
- matrix variables
- names
You may specify certain extra keys for any inline table that will determine whether or not to apply that entry. These modifiers may be combined with others and any negative evaluation will immediately cause the entry to be skipped.
"},{"location":"config/environment/advanced/#allowed-values","title":"Allowed values","text":"The
pyproject.toml hatch.tomlifkey represents the allowed values for that condition. If the value of the condition is not listed, then that entry will not be applied:[tool.hatch.envs.test.overrides]\nmatrix.version.python = { value = \"pypy\", if = [\"3.14\"] }\nmatrix.version.env-vars = [\n { key = \"KEY1\", value = \"VALUE1\", if = [\"42\"] },\n { key = \"KEY2\", value = \"VALUE2\", if = [\"3.14\"] },\n]\n\n[[tool.hatch.envs.test.matrix]]\nversion = [\"42\", \"3.14\"]\n
"},{"location":"config/environment/advanced/#specific-platforms","title":"Specific platforms","text":"[envs.test.overrides]\nmatrix.version.python = { value = \"pypy\", if = [\"3.14\"] }\nmatrix.version.env-vars = [\n { key = \"KEY1\", value = \"VALUE1\", if = [\"42\"] },\n { key = \"KEY2\", value = \"VALUE2\", if = [\"3.14\"] },\n]\n\n[[envs.test.matrix]]\nversion = [\"42\", \"3.14\"]\nThe
pyproject.toml hatch.tomlplatformkey represents the desired platforms. If the current platform is not listed, then that entry will not be applied:[tool.hatch.envs.test.overrides]\nenv.EXPERIMENTAL.python = { value = \"pypy\", if = [\"1\"], platform = [\"macos\"] }\nmatrix.version.env-vars = [\n { key = \"KEY1\", value = \"VALUE1\", if = [\"42\"], platform = [\"linux\"] },\n { key = \"KEY2\", value = \"VALUE2\", if = [\"3.14\"] },\n]\n\n[[tool.hatch.envs.test.matrix]]\nversion = [\"42\", \"3.14\"]\n
"},{"location":"config/environment/advanced/#required-environment-variables","title":"Required environment variables","text":"[envs.test.overrides]\nenv.EXPERIMENTAL.python = { value = \"pypy\", if = [\"1\"], platform = [\"macos\"] }\nmatrix.version.env-vars = [\n { key = \"KEY1\", value = \"VALUE1\", if = [\"42\"], platform = [\"linux\"] },\n { key = \"KEY2\", value = \"VALUE2\", if = [\"3.14\"] },\n]\n\n[[envs.test.matrix]]\nversion = [\"42\", \"3.14\"]\nThe
pyproject.toml hatch.tomlenvkey represents the required environment variables. If any of the listed environment variables are not set or the defined value does not match, then that entry will not be applied:[tool.hatch.envs.test.overrides]\nplatform.windows.python = { value = \"pypy\", env = [\"EXPERIMENTAL\"] }\nmatrix.version.env-vars = [\n { key = \"KEY1\", value = \"VALUE1\", if = [\"42\"], env = [\"FOO\", \"BAR=BAZ\"] },\n { key = \"KEY2\", value = \"VALUE2\", if = [\"3.14\"] },\n]\n\n[[tool.hatch.envs.test.matrix]]\nversion = [\"42\", \"3.14\"]\n
"},{"location":"config/environment/overview/","title":"Environment configuration","text":"[envs.test.overrides]\nplatform.windows.python = { value = \"pypy\", env = [\"EXPERIMENTAL\"] }\nmatrix.version.env-vars = [\n { key = \"KEY1\", value = \"VALUE1\", if = [\"42\"], env = [\"FOO\", \"BAR=BAZ\"] },\n { key = \"KEY2\", value = \"VALUE2\", if = [\"3.14\"] },\n]\n\n[[envs.test.matrix]]\nversion = [\"42\", \"3.14\"]\nAll environments are defined as sections within the
pyproject.toml hatch.tomltool.hatch.envstable.[tool.hatch.envs.<ENV_NAME>]\n[envs.<ENV_NAME>]\nThe storage location for environments is completely configurable.
Unless an environment is explicitly selected on the command line, the
defaultenvironment will be used. The type of this environment defaults tovirtual.Info
Environments prefixed by
"},{"location":"config/environment/overview/#inheritance","title":"Inheritance","text":"hatch-are used for special purposes e.g. testing.All environments inherit from the environment defined by its
templateoption, which defaults todefault.So for the following configuration:
pyproject.toml hatch.toml[tool.hatch.envs.foo]\ntype = \"baz\"\nskip-install = true\n\n[tool.hatch.envs.bar]\ntemplate = \"foo\"\nskip-install = false\n[envs.foo]\ntype = \"baz\"\nskip-install = true\n\n[envs.bar]\ntemplate = \"foo\"\nskip-install = false\nthe environment
barwill be of typebazwithskip-installset tofalse.Note
Environments do not inherit matrices.
"},{"location":"config/environment/overview/#self-referential-environments","title":"Self-referential environments","text":"You can disable inheritance by setting
pyproject.toml hatch.tomltemplateto the environment's own name:[tool.hatch.envs.foo]\ntemplate = \"foo\"\n
"},{"location":"config/environment/overview/#detached-environments","title":"Detached environments","text":"[envs.foo]\ntemplate = \"foo\"\nA common use case is standalone environments that do not require inheritance nor the installation of the project, such as for linting or sometimes building documentation. Enabling the
pyproject.toml hatch.tomldetachedoption will make the environment self-referential and will skip project installation:[tool.hatch.envs.lint]\ndetached = true\n
"},{"location":"config/environment/overview/#dependencies","title":"Dependencies","text":"[envs.lint]\ndetached = true\nYou can install dependencies in addition to the ones defined by your project's metadata. Entries support context formatting.
pyproject.toml hatch.toml[tool.hatch.envs.test]\ndependencies = [\n \"coverage[toml]\",\n \"pytest\",\n \"pytest-cov\",\n \"pytest-mock\",\n]\n[envs.test]\ndependencies = [\n \"coverage[toml]\",\n \"pytest\",\n \"pytest-cov\",\n \"pytest-mock\",\n]\nIf you define environments with dependencies that only slightly differ from their inherited environments, you can use the
pyproject.toml hatch.tomlextra-dependenciesoption to avoid redeclaring thedependenciesoption:[tool.hatch.envs.default]\ndependencies = [\n \"foo\",\n \"bar\",\n]\n\n[tool.hatch.envs.experimental]\nextra-dependencies = [\n \"baz\",\n]\n[envs.default]\ndependencies = [\n \"foo\",\n \"bar\",\n]\n\n[envs.experimental]\nextra-dependencies = [\n \"baz\",\n]\nTip
Hatch uses pip to install dependencies so any configuration it supports Hatch does as well. For example, if you wanted to only use a private repository you could set the
"},{"location":"config/environment/overview/#installation","title":"Installation","text":""},{"location":"config/environment/overview/#features","title":"Features (extras)","text":"PIP_INDEX_URLenvironment variable.If your project defines optional dependencies, you can select which groups to install using the
pyproject.toml hatch.tomlfeaturesoption:[tool.hatch.envs.nightly]\nfeatures = [\n \"server\",\n \"grpc\",\n]\n[envs.nightly]\nfeatures = [\n \"server\",\n \"grpc\",\n]\nNote
Features/optional dependencies are also known as
"},{"location":"config/environment/overview/#dev-mode","title":"Dev mode","text":"extrasin other tools.By default, environments will always reflect the current state of your project on disk. Set
pyproject.toml hatch.tomldev-modetofalseto disable this behavior:[tool.hatch.envs.static]\ndev-mode = false\n
"},{"location":"config/environment/overview/#skip-install","title":"Skip install","text":"[envs.static]\ndev-mode = false\nBy default, environments will install your project during creation. To ignore this step, set
pyproject.toml hatch.tomlskip-installtotrue:[tool.hatch.envs.lint]\nskip-install = true\n
"},{"location":"config/environment/overview/#environment-variables","title":"Environment variables","text":""},{"location":"config/environment/overview/#defined","title":"Defined","text":"[envs.lint]\nskip-install = true\nYou can define environment variables with the
pyproject.toml hatch.tomlenv-varsoption:[tool.hatch.envs.docs]\ndependencies = [\n \"mkdocs\"\n]\n[tool.hatch.envs.docs.env-vars]\nSOURCE_DATE_EPOCH = \"1580601600\"\n[envs.docs]\ndependencies = [\n \"mkdocs\"\n]\n[envs.docs.env-vars]\nSOURCE_DATE_EPOCH = \"1580601600\"\nValues support context formatting.
"},{"location":"config/environment/overview/#filters","title":"Filters","text":"By default, environments will have access to all environment variables. You can filter with wildcard patterns using the
pyproject.toml hatch.tomlenv-include/env-excludeoptions:[tool.hatch.envs.<ENV_NAME>]\nenv-include = [\n \"FOO*\",\n]\nenv-exclude = [\n \"BAR\",\n]\n[envs.<ENV_NAME>]\nenv-include = [\n \"FOO*\",\n]\nenv-exclude = [\n \"BAR\",\n]\nExclusion patterns take precedence but will never affect defined environment variables.
"},{"location":"config/environment/overview/#scripts","title":"Scripts","text":"You can define named scripts that may be executed or referenced at the beginning of other scripts. Context formatting is supported.
For example, in the following configuration:
pyproject.toml hatch.toml[tool.hatch.envs.test]\ndependencies = [\n \"coverage[toml]\",\n \"pytest\",\n \"pytest-cov\",\n \"pytest-mock\",\n]\n[tool.hatch.envs.test.scripts]\nrun-coverage = \"pytest --cov-config=pyproject.toml --cov=pkg --cov=tests\"\nrun = \"run-coverage --no-cov\"\n[envs.test]\ndependencies = [\n \"coverage[toml]\",\n \"pytest\",\n \"pytest-cov\",\n \"pytest-mock\",\n]\n[envs.test.scripts]\nrun-coverage = \"pytest --cov-config=pyproject.toml --cov=pkg --cov=tests\"\nrun = \"run-coverage --no-cov\"\nthe
runscript would be expanded to:pytest --cov-config=pyproject.toml --cov=pkg --cov=tests --no-cov\nScripts can also be defined as an array of strings.
pyproject.toml hatch.toml[tool.hatch.envs.style]\ndetached = true\ndependencies = [\n \"flake8\",\n \"black\",\n \"isort\",\n]\n[tool.hatch.envs.style.scripts]\ncheck = [\n \"flake8 .\",\n \"black --check --diff .\",\n \"isort --check-only --diff .\",\n]\nfmt = [\n \"isort .\",\n \"black .\",\n \"check\",\n]\n[envs.style]\ndetached = true\ndependencies = [\n \"flake8\",\n \"black\",\n \"isort\",\n]\n[envs.style.scripts]\ncheck = [\n \"flake8 .\",\n \"black --check --diff .\",\n \"isort --check-only --diff .\",\n]\nfmt = [\n \"isort .\",\n \"black .\",\n \"check\",\n]\nSimilar to make, you can ignore the exit code of commands that start with
pyproject.toml hatch.toml-(a hyphen). For example, the scripterrordefined by the following configuration would halt after the second command with3as the exit code:[tool.hatch.envs.test.scripts]\nerror = [\n \"- exit 1\",\n \"exit 3\",\n \"exit 0\",\n]\n
"},{"location":"config/environment/overview/#extra-scripts","title":"Extra scripts","text":"[envs.test.scripts]\nerror = [\n \"- exit 1\",\n \"exit 3\",\n \"exit 0\",\n]\nIndividual scripts inherit from parent environments just like options. To guarantee that individual scripts do not override those defined by parent environments, you can use the
"},{"location":"config/environment/overview/#commands","title":"Commands","text":"extra-scriptsoption instead which is only capable of adding scripts that have not been defined.All commands are able to use any defined scripts. Also like scripts, context formatting is supported and the exit code of commands that start with a hyphen will be ignored.
"},{"location":"config/environment/overview/#pre-install","title":"Pre-install","text":"You can run commands immediately before environments install your project.
pyproject.toml hatch.toml[tool.hatch.envs.<ENV_NAME>]\npre-install-commands = [\n \"...\",\n]\n
"},{"location":"config/environment/overview/#post-install","title":"Post-install","text":"[envs.<ENV_NAME>]\npre-install-commands = [\n \"...\",\n]\nYou can run commands immediately after environments install your project.
pyproject.toml hatch.toml[tool.hatch.envs.<ENV_NAME>]\npost-install-commands = [\n \"...\",\n]\n
"},{"location":"config/environment/overview/#python-version","title":"Python version","text":"[envs.<ENV_NAME>]\npost-install-commands = [\n \"...\",\n]\nThe
pyproject.toml hatch.tomlpythonoption specifies which version of Python to use, or an absolute path to a Python interpreter:[tool.hatch.envs.<ENV_NAME>]\npython = \"3.10\"\n[envs.<ENV_NAME>]\npython = \"3.10\"\nAll environment types should respect this option.
"},{"location":"config/environment/overview/#supported-platforms","title":"Supported platforms","text":"The
pyproject.toml hatch.tomlplatformsoption indicates the operating systems with which the environment is compatible:[tool.hatch.envs.<ENV_NAME>]\nplatforms = [\"linux\", \"windows\", \"macos\"]\n[envs.<ENV_NAME>]\nplatforms = [\"linux\", \"windows\", \"macos\"]\nThe following platforms are supported:
linuxwindowsmacos
If unspecified, the environment is assumed to be compatible with all platforms.
"},{"location":"config/environment/overview/#description","title":"Description","text":"The
pyproject.toml hatch.tomldescriptionoption is purely informational and is displayed in the output of theenv showcommand:[tool.hatch.envs.<ENV_NAME>]\ndescription = \"\"\"\nLorem ipsum ...\n\"\"\"\n
"},{"location":"config/environment/overview/#type","title":"Type","text":"[envs.<ENV_NAME>]\ndescription = \"\"\"\nLorem ipsum ...\n\"\"\"\nAn environment's
"},{"location":"config/internal/static-analysis/","title":"Static analysis configuration","text":"typedetermines which environment plugin will be used for management. The only built-in environment type isvirtual, which uses virtual Python environments.Static analysis performed by the
fmtcommand is (by default) backed entirely by Ruff.Hatch provides default settings that user configuration can extend.
"},{"location":"config/internal/static-analysis/#extending-config","title":"Extending config","text":"When defining your configuration, be sure to use options that are prefixed by
pyproject.toml ruff.tomlextend-such asextend-select, for example:[tool.ruff.format]\npreview = true\nquote-style = \"single\"\n\n[tool.ruff.lint]\npreview = true\nextend-select = [\"C901\"]\n\n[tool.ruff.lint.extend-per-file-ignores]\n\"docs/.hooks/*\" = [\"INP001\", \"T201\"]\n\n[tool.ruff.lint.isort]\nknown-first-party = [\"foo\", \"bar\"]\n[format]\npreview = true\nquote-style = \"single\"\n\n[lint]\npreview = true\nextend-select = [\"C901\"]\n\n[lint.extend-per-file-ignores]\n\"docs/.hooks/*\" = [\"INP001\", \"T201\"]\n\n[lint.isort]\nknown-first-party = [\"foo\", \"bar\"]\nNote
When not persisting config, there is no need to explicitly extend the defaults as Hatch automatically handles that.
"},{"location":"config/internal/static-analysis/#persistent-config","title":"Persistent config","text":"If you want to store the default configuration in the project, set an explicit path like so:
pyproject.toml hatch.toml[tool.hatch.envs.hatch-static-analysis]\nconfig-path = \"ruff_defaults.toml\"\n[envs.hatch-static-analysis]\nconfig-path = \"ruff_defaults.toml\"\nThen instruct Ruff to consider your configuration as an extension of the default file:
pyproject.toml ruff.toml[tool.ruff]\nextend = \"ruff_defaults.toml\"\nextend = \"ruff_defaults.toml\"\nAnytime you wish to update the defaults (such as when upgrading Hatch), you must run the
fmtcommand once with the--syncflag e.g.:hatch fmt --check --sync\nTip
This is the recommended approach since it allows other tools like IDEs to use the default configuration.
"},{"location":"config/internal/static-analysis/#no-config","title":"No config","text":"If you don't want Hatch to use any of its default configuration and rely entirely on yours, set the path to anything and then simply don't
pyproject.toml hatch.tomlextendin your Ruff config:[tool.hatch.envs.hatch-static-analysis]\nconfig-path = \"none\"\n
"},{"location":"config/internal/static-analysis/#customize-behavior","title":"Customize behavior","text":"[envs.hatch-static-analysis]\nconfig-path = \"none\"\nYou can fully alter the behavior of the environment used by the
"},{"location":"config/internal/static-analysis/#dependencies","title":"Dependencies","text":"fmtcommand. See the how-to for a detailed example.Pin the particular version of Ruff by explicitly defining the environment dependencies:
pyproject.toml hatch.toml[tool.hatch.envs.hatch-static-analysis]\ndependencies = [\"ruff==X.Y.Z\"]\n
"},{"location":"config/internal/static-analysis/#scripts","title":"Scripts","text":"[envs.hatch-static-analysis]\ndependencies = [\"ruff==X.Y.Z\"]\nIf you want to change the default commands that are executed, you can override the scripts. The following four scripts must be defined:
pyproject.toml hatch.toml[tool.hatch.envs.hatch-static-analysis.scripts]\nformat-check = \"...\"\nformat-fix = \"...\"\nlint-check = \"...\"\nlint-fix = \"...\"\n[envs.hatch-static-analysis.scripts]\nformat-check = \"...\"\nformat-fix = \"...\"\nlint-check = \"...\"\nlint-fix = \"...\"\nThe
format-*scripts correspond to the--formatter/-fflag while thelint-*scripts correspond to the--linter/-lflag. The*-fixscripts run by default while the*-checkscripts correspond to the--checkflag.Reminder
If you choose to use different tools for static analysis, be sure to update the required dependencies.
"},{"location":"config/internal/static-analysis/#installer","title":"Installer","text":"By default, UV is enabled. You may disable that behavior as follows:
pyproject.toml hatch.toml[tool.hatch.envs.hatch-static-analysis]\ninstaller = \"pip\"\n
"},{"location":"config/internal/static-analysis/#default-settings","title":"Default settings","text":""},{"location":"config/internal/static-analysis/#non-rule-settings","title":"Non-rule settings","text":"[envs.hatch-static-analysis]\ninstaller = \"pip\"\n- Line length set to 120
- Docstring formatting enabled with line length set to 80
- Only absolute imports are allowed, except for tests
- The normalized project name is a known first party import
**/scripts/*: INP001, T201**/tests/**/*: PLC1901, PLR2004, PLR6301, S, TID252
The following rules are based on version 0.4.5 of Ruff. Rules with a P are only selected when preview mode is enabled.
There are 525 selected stable rules and 129 selected preview rules.
Selected rules- A001, A002, A003
- ARG001, ARG002, ARG003, ARG004, ARG005
- ASYNC100, ASYNC101, ASYNC102
- B002, B003, B004, B005, B006, B007, B008, B009, B010, B011, B012, B013, B014, B015, B016, B017, B018, B019, B020, B021, B022, B023, B024, B025, B026, B028, B029, B030, B031, B032, B033, B034, B035, B904, B905, B909P
- BLE001
- C400, C401, C402, C403, C404, C405, C406, C408, C409, C410, C411, C413, C414, C415, C416, C417, C418, C419
- COM818
- DTZ001, DTZ002, DTZ003, DTZ004, DTZ005, DTZ006, DTZ007, DTZ011, DTZ012
- E101, E112P, E113P, E115P, E116P, E201P, E202P, E203P, E211P, E221P, E222P, E223P, E224P, E225P, E226P, E227P, E228P, E231P, E241P, E242P, E251P, E252P, E261P, E262P, E265P, E266P, E271P, E272P, E273P, E274P, E275P, E401, E402, E502P, E701, E702, E703, E711, E712, E713, E714, E721, E722, E731, E741, E742, E743, E902, E999
- EM101, EM102, EM103
- EXE001, EXE002, EXE003, EXE004, EXE005
- F401, F402, F403, F404, F405, F406, F407, F501, F502, F503, F504, F505, F506, F507, F508, F509, F521, F522, F523, F524, F525, F541, F601, F602, F621, F622, F631, F632, F633, F634, F701, F702, F704, F706, F707, F722, F811, F821, F822, F823, F841, F842, F901
- FA100, FA102
- FBT001, FBT002
- FLY002
- FURB105P, FURB110P, FURB113P, FURB116P, FURB118P, FURB129P, FURB131P, FURB132P, FURB136P, FURB142P, FURB145P, FURB148P, FURB152P, FURB157P, FURB161P, FURB163P, FURB164P, FURB166P, FURB167P, FURB168P, FURB169P, FURB171P, FURB177P, FURB180P, FURB181P, FURB187P, FURB192P
- G001, G002, G003, G004, G010, G101, G201, G202
- I001, I002
- ICN001, ICN002, ICN003
- INP001
- INT001, INT002, INT003
- ISC003
- LOG001, LOG002, LOG007, LOG009
- N801, N802, N803, N804, N805, N806, N807, N811, N812, N813, N814, N815, N816, N817, N818, N999
- PERF101, PERF102, PERF401, PERF402, PERF403P
- PGH005
- PIE790, PIE794, PIE796, PIE800, PIE804, PIE807, PIE808, PIE810
- PLC0105, PLC0131, PLC0132, PLC0205, PLC0208, PLC0414, PLC0415P, PLC1901P, PLC2401P, PLC2403P, PLC2701P, PLC2801P, PLC3002
- PLE0100, PLE0101, PLE0116, PLE0117, PLE0118, PLE0237, PLE0241, PLE0302, PLE0307, PLE0604, PLE0605, PLE0115P, PLE0303P, PLE0304P, PLE0305P, PLE0308P, PLE0309P, PLE0643P, PLE0704P, PLE1142, PLE1205, PLE1206, PLE1300, PLE1307, PLE1310, PLE1507, PLE1700, PLE1132P, PLE1141P, PLE1519P, PLE1520P, PLE2502, PLE2510, PLE2512, PLE2513, PLE2514, PLE2515, PLE4703P
- PLR0124, PLR0133, PLR0206, PLR0402, PLR0202P, PLR0203P, PLR1701, PLR1711, PLR1714, PLR1722, PLR1704P, PLR1730P, PLR1733P, PLR1736P, PLR2004, PLR2044P, PLR5501, PLR6104P, PLR6201P, PLR6301P
- PLW0120, PLW0127, PLW0129, PLW0131, PLW0406, PLW0602, PLW0603, PLW0711, PLW0108P, PLW0128P, PLW0133P, PLW0177P, PLW0211P, PLW0245P, PLW0604P, PLW0642P, PLW1508, PLW1509, PLW1510, PLW1501P, PLW1514P, PLW1641P, PLW2901, PLW2101P, PLW3301, PLW3201P
- PT001, PT002, PT003, PT006, PT007, PT008, PT009, PT010, PT011, PT012, PT013, PT014, PT015, PT016, PT017, PT018, PT019, PT020, PT021, PT022, PT023, PT024, PT025, PT026, PT027
- PYI001, PYI002, PYI003, PYI004, PYI005, PYI006, PYI007, PYI008, PYI009, PYI010, PYI011, PYI012, PYI013, PYI014, PYI015, PYI016, PYI017, PYI018, PYI019, PYI020, PYI021, PYI024, PYI025, PYI026, PYI029, PYI030, PYI032, PYI033, PYI034, PYI035, PYI036, PYI041, PYI042, PYI043, PYI044, PYI045, PYI046, PYI047, PYI048, PYI049, PYI050, PYI051, PYI052, PYI053, PYI054, PYI055, PYI056, PYI058, PYI059P, PYI062P
- RET503, RET504, RET505, RET506, RET507, RET508
- RSE102
- RUF001, RUF002, RUF003, RUF005, RUF006, RUF007, RUF008, RUF009, RUF010, RUF012, RUF013, RUF015, RUF016, RUF017, RUF018, RUF019, RUF020, RUF021P, RUF022P, RUF023P, RUF024P, RUF025P, RUF026P, RUF027P, RUF028P, RUF029P, RUF100, RUF101P
- S101, S102, S103, S104, S105, S106, S107, S108, S110, S112, S113, S201, S202, S301, S302, S303, S304, S305, S306, S307, S308, S310, S311, S312, S313, S314, S315, S316, S317, S318, S319, S320, S321, S323, S324, S401P, S402P, S403P, S405P, S406P, S407P, S408P, S409P, S411P, S412P, S413P, S415P, S501, S502, S503, S504, S505, S506, S507, S508, S509, S601, S602, S604, S605, S606, S607, S608, S609, S611, S612, S610P, S701, S702
- SIM101, SIM102, SIM103, SIM105, SIM107, SIM108, SIM109, SIM110, SIM112, SIM113, SIM114, SIM115, SIM116, SIM117, SIM118, SIM201, SIM202, SIM208, SIM210, SIM211, SIM212, SIM220, SIM221, SIM222, SIM223, SIM300, SIM910, SIM911
- SLF001
- SLOT000, SLOT001, SLOT002
- T100, T201, T203
- TCH001, TCH002, TCH003, TCH004, TCH005, TCH010
- TD004, TD005, TD006, TD007
- TID251, TID252, TID253
- TRIO100, TRIO105, TRIO109, TRIO110, TRIO115
- TRY002, TRY003, TRY004, TRY201, TRY300, TRY301, TRY302, TRY400, TRY401
- UP001, UP003, UP004, UP005, UP006, UP007, UP008, UP009, UP010, UP011, UP012, UP013, UP014, UP015, UP017, UP018, UP019, UP020, UP021, UP022, UP023, UP024, UP025, UP026, UP027, UP028, UP029, UP030, UP031, UP032, UP033, UP034, UP035, UP036, UP037, UP038, UP039, UP040, UP041, UP042P
- W291, W292, W293, W391P, W505, W605
- YTT101, YTT102, YTT103, YTT201, YTT202, YTT203, YTT204, YTT301, YTT302, YTT303
There are 175 unselected rules.
Unselected rules- AIR001
- ANN001, ANN002, ANN003, ANN101, ANN102, ANN201, ANN202, ANN204, ANN205, ANN206, ANN401
- B027
- C901
- COM812, COM819
- CPY001
- D100, D101, D102, D103, D104, D105, D106, D107, D200, D201, D202, D203, D204, D205, D206, D207, D208, D209, D210, D211, D212, D213, D214, D215, D300, D301, D400, D401, D402, D403, D404, D405, D406, D407, D408, D409, D410, D411, D412, D413, D414, D415, D416, D417, D418, D419
- DJ001, DJ003, DJ006, DJ007, DJ008, DJ012, DJ013
- E111, E114, E117, E301, E302, E303, E304, E305, E306, E501
- ERA001
- FBT003
- FIX001, FIX002, FIX003, FIX004
- FURB101, FURB103, FURB140
- ISC001, ISC002
- NPY001, NPY002, NPY003, NPY201
- PD002, PD003, PD004, PD007, PD008, PD009, PD010, PD011, PD012, PD013, PD015, PD101, PD901
- PERF203
- PGH001, PGH002, PGH003, PGH004
- PLR0904, PLR0911, PLR0912, PLR0913, PLR0914, PLR0915, PLR0916, PLR0917, PLR1702, PLR1706
- PT004, PT005
- PTH100, PTH101, PTH102, PTH103, PTH104, PTH105, PTH106, PTH107, PTH108, PTH109, PTH110, PTH111, PTH112, PTH113, PTH114, PTH115, PTH116, PTH117, PTH118, PTH119, PTH120, PTH121, PTH122, PTH123, PTH124, PTH201, PTH202, PTH203, PTH204, PTH205, PTH206, PTH207
- Q000, Q001, Q002, Q003, Q004
- RET501, RET502
- RUF011, RUF200
- S404, S410, S603
- SIM401
- TD001, TD002, TD003
- TRY200
- W191
Check out the testing overview tutorial for a more comprehensive walk-through.
"},{"location":"config/internal/testing/#settings","title":"Settings","text":"If an option has a corresponding
"},{"location":"config/internal/testing/#default-arguments","title":"Default arguments","text":"testcommand flag, the flag will always take precedence.You can define default arguments for the
pyproject.toml hatch.tomltestcommand by setting thedefault-argsoption, which must be an array of strings. The following is the default configuration:[tool.hatch.envs.hatch-test]\ndefault-args = [\"tests\"]\n
"},{"location":"config/internal/testing/#extra-arguments","title":"Extra arguments","text":"[envs.hatch-test]\ndefault-args = [\"tests\"]\nYou can define extra internal arguments for test scripts by setting the
pyproject.toml hatch.tomlextra-argsoption, which must be an array of strings. For example, if you wanted to increase the verbosity ofpytest, you could set the following:[tool.hatch.envs.hatch-test]\nextra-args = [\"-vv\"]\n
"},{"location":"config/internal/testing/#randomize-test-order","title":"Randomize test order","text":"[envs.hatch-test]\nextra-args = [\"-vv\"]\nYou can randomize the order of tests by enabling the
pyproject.toml hatch.tomlrandomizeoption which corresponds to the--randomize/-rflag:[tool.hatch.envs.hatch-test]\nrandomize = true\n
"},{"location":"config/internal/testing/#parallelize-test-execution","title":"Parallelize test execution","text":"[envs.hatch-test]\nrandomize = true\nYou can parallelize test execution by enabling the
pyproject.toml hatch.tomlparalleloption which corresponds to the--parallel/-pflag:[tool.hatch.envs.hatch-test]\nparallel = true\n
"},{"location":"config/internal/testing/#retry-failed-tests","title":"Retry failed tests","text":"[envs.hatch-test]\nparallel = true\nYou can retry failed tests by setting the
pyproject.toml hatch.tomlretriesoption which corresponds to the--retriesflag:[tool.hatch.envs.hatch-test]\nretries = 2\n[envs.hatch-test]\nretries = 2\nYou can also set the number of seconds to wait between retries by setting the
pyproject.toml hatch.tomlretry-delayoption which corresponds to the--retry-delayflag:[tool.hatch.envs.hatch-test]\nretry-delay = 1\n
"},{"location":"config/internal/testing/#customize-environment","title":"Customize environment","text":"[envs.hatch-test]\nretry-delay = 1\nYou can fully alter the behavior of the environment used by the
"},{"location":"config/internal/testing/#dependencies","title":"Dependencies","text":"testcommand.You can define extra dependencies that your tests may require:
pyproject.toml hatch.toml[tool.hatch.envs.hatch-test]\nextra-dependencies = [\n \"pyfakefs\",\n \"pytest-asyncio\",\n \"pytest-benchmark\",\n \"pytest-memray\",\n \"pytest-playwright\",\n \"pytest-print\",\n]\n[envs.hatch-test]\nextra-dependencies = [\n \"pyfakefs\",\n \"pytest-asyncio\",\n \"pytest-benchmark\",\n \"pytest-memray\",\n \"pytest-playwright\",\n \"pytest-print\",\n]\nThe following is the default configuration:
pyproject.toml hatch.toml[tool.hatch.envs.hatch-test]\ndependencies = [\n \"coverage-enable-subprocess==1.0\",\n \"coverage[toml]~=7.4\",\n \"pytest~=8.1\",\n \"pytest-mock~=3.12\",\n \"pytest-randomly~=3.15\",\n \"pytest-rerunfailures~=14.0\",\n \"pytest-xdist[psutil]~=3.5\",\n]\n
"},{"location":"config/internal/testing/#matrix","title":"Matrix","text":"[envs.hatch-test]\ndependencies = [\n \"coverage-enable-subprocess==1.0\",\n \"coverage[toml]~=7.4\",\n \"pytest~=8.1\",\n \"pytest-mock~=3.12\",\n \"pytest-randomly~=3.15\",\n \"pytest-rerunfailures~=14.0\",\n \"pytest-xdist[psutil]~=3.5\",\n]\nYou can override the default series of matrices:
pyproject.toml hatch.toml[[tool.hatch.envs.hatch-test.matrix]]\npython = [\"3.13\", \"3.12\", \"3.11\", \"3.10\", \"3.9\", \"3.8\"]\n
"},{"location":"config/internal/testing/#scripts","title":"Scripts","text":"[[envs.hatch-test.matrix]]\npython = [\"3.13\", \"3.12\", \"3.11\", \"3.10\", \"3.9\", \"3.8\"]\nIf you want to change the default commands that are executed, you can override the scripts. The following default scripts must be redefined:
pyproject.toml hatch.toml[tool.hatch.envs.hatch-test.scripts]\nrun = \"pytest{env:HATCH_TEST_ARGS:} {args}\"\nrun-cov = \"coverage run -m pytest{env:HATCH_TEST_ARGS:} {args}\"\ncov-combine = \"coverage combine\"\ncov-report = \"coverage report\"\n[envs.hatch-test.scripts]\nrun = \"pytest{env:HATCH_TEST_ARGS:} {args}\"\nrun-cov = \"coverage run -m pytest{env:HATCH_TEST_ARGS:} {args}\"\ncov-combine = \"coverage combine\"\ncov-report = \"coverage report\"\nThe
runscript is the default behavior while therun-covscript is used instead when measuring code coverage. Thecov-combinescript runs after all tests complete when measuring code coverage, as well as thecov-reportscript when not using the--cover-quietflag.Note
The
"},{"location":"config/internal/testing/#installer","title":"Installer","text":"HATCH_TEST_ARGSenvironment variable is how thetestcommand's flags are translated and internally populated without affecting the user's arguments. This is also the way that extra arguments are passed.By default, UV is enabled. You may disable that behavior as follows:
pyproject.toml hatch.toml[tool.hatch.envs.hatch-test]\ninstaller = \"pip\"\n
"},{"location":"history/hatch/","title":"Hatch history","text":"[envs.hatch-test]\ninstaller = \"pip\"\nAll notable changes to Hatch will be documented in this file.
The format is based on Keep a Changelog, and this project adheres to Semantic Versioning.
"},{"location":"history/hatch/#unreleased","title":"Unreleased","text":""},{"location":"history/hatch/#hatch-v1.13.0","title":"1.13.0 - 2024-10-13","text":"Added:
- Support managing Python 3.13 distributions
Changed:
- The
run/env runandtestcommands now treat inclusion variable options as an intersection rather than a union to allow for specific targeting of environments
Added:
- Add ability to control the source of Python distributions
- Upgrade Ruff to 0.4.5
- Upgrade PyApp to 0.22.0 for binary builds
Fixed:
- The
fmtcommand no longer hides the commands that are being executed - Add default timeout for network requests, useful when installing Python distributions
- Fix syntax highlighting contrast for the
config showcommand
Added:
- Add official GitHub Action for installing Hatch
Fixed:
- Fix
terminal.styles.spinnerconfiguration - Fix entry points in the pre-built distributions that binaries use
Added:
- Upgrade PyApp to 0.21.1 for binary builds
Fixed:
- On Linux, install the highest compatible Python distribution variant based on CPU architecture rather than assuming recent hardware
Changed:
- The
run/env run,fmtandshellcommands now only change the current working directory to the project root if not already inside the project - The
shellcommand now accepts a single argument to specify the environment to enter which overrides the standard choice mechanisms. The arguments determining shell options have been converted to flags.
Added:
- Add
testcommand - The
runcommand can now execute scripts that define inline metadata for dependencies and Python version constraints - The
virtualenvironment type now supports the ability to use UV in place of pip & virtualenv - Add
self reportcommand for submitting pre-populated bug reports to GitHub - The reserved environment used for static analysis is now completely configurable
- Add the following methods to the
environmentinterface for complete control over output during life cycle management:app_status_creation,app_status_pre_installation,app_status_post_installation,app_status_project_installation,app_status_dependency_state_check,app_status_dependency_installation_check,app_status_dependency_synchronization - Add binaries for 32-bit versions of Windows
- Read configuration from any
~/.pypircfile for theindexpublisher - Use the Git user as the default username for new project URL metadata
- Add
HATCH_DEBUGenvironment variable that when enabled will show local variables in the case of unhandled tracebacks - The
env showcommand now outputs data about all internal environments when using the--jsonflag - Upgrade default CPython distributions to 20240415
- Upgrade default PyPy distributions to 7.3.15
- Upgrade Ruff to 0.4.2
- Upgrade PyApp to 0.19.0 for binary builds
- Bump the minimum supported version of Hatchling to 1.24.2
- Bump the minimum supported version of virtualenv to 20.26.1
Fixed:
- Maintain consistent data paths for case insensitive file systems
- When projects derive dependencies from metadata hooks, there is now by default a status indicator for when the hooks are executed for better responsiveness
- Properly support projects with a
pyproject.tomlfile but noprojecttable e.g. applications - Fix the
fmtcommand when automatically installing plugin dependencies - Fix dependency inheritance for the template of the
typesenvironment for new projects - Fix warnings related to tar file extraction on Python 3.12+ when unpacking Python distributions for installation
- De-select Ruff rule
E501for thefmtcommand by default since it conflicts with the formatter - Fix colored output from build targets on the first run (build environment creation status indicator issue)
- Set the
packagingdependency version as>=23.2to avoid its URL validation which can conflict with context formatting - Fix the exit code when there happens to be an unhandled exception
- No longer capture both stdout and stderr streams when parsing metadata payloads from build environments
- Fix the
README.mdfile template for new projects to avoid Markdown linting issues
Fixed:
- Limit the maximum version of virtualenv due to a backward incompatible change
- Upgrade PyApp to 0.12.0 for binary builds
Fixed:
- Limit the maximum version of Hatchling in anticipation of backward incompatible changes
Fixed:
- Fix loading of local plugins to account for newly released versions of a dependency
Fixed:
- Fix the default token variable name for publishing to PyPI
Fixed:
- Ensure that the
dependency_hashmethod of theenvironmentinterface is called aftersync_dependenciesfor cases where the hash is only known at that point, such as for dependency lockers - Only acknowledge the
HATCH_PYTHON_VARIANT_*environment variables for Python resolution for supported platforms and architectures - Fix Python resolution when there are metadata hooks with unsatisfied dependencies
Changed:
- Environments prefixed by
hatch-are now considered internal and used for special purposes such as configuration for static analysis
Added:
- Enable docstring formatting by default for static analysis
- Allow for overriding config of internal environments
- Concretely state the expected API contract for the environment interface methods
findandcheck_compatibility - Upgrade Ruff to 0.1.8
- Bump the minimum supported version of Hatchling to 1.21.0
Fixed:
- Ignore a project's Python requirement for environments where the project is not installed
- When not persisting config for static analysis, properly manage internal settings when Ruff's top level table already exists
- Ignore compatibility checks when environments have already been created, significantly improving performance of environment usage
- Properly allow overriding of the
pathoption for thevirtualenvironment type - Fix nushell activation on non-Windows systems
Fixed:
- Fix regression in calling subprocesses with updated PATH
- Fix automatic installation of environment plugins when running as a standalone binary
- Change default location of Python installations
Changed:
- Drop support for Python 3.7
- The
get_build_processmethod of theenvironmentinterface has been removed; plugins should use the newrun_buildermethod instead - Remove
pyperclipdependency and the--copyflag of theconfig findcommand - When running the
buildcommand all output from builders is now displayed as-is in real time without the stripping of ANSI codes - Version information (for Hatch itself) is now derived from Git
Added:
- Support Python 3.12
- Add installers and standalone binaries
- Add the ability to manage Python installations
- Add
fmtcommand - The
virtualenvironment type can now automatically download requested versions of Python that are not installed - Add
dependency_hashmethod to theenvironmentinterface - The state of installed dependencies for environments is saved as metadata so if dependency definitions have not changed then no checking is performed, which can be computationally expensive
- The
buildcommand now supports backends other than Hatchling - Allow the use of
featuresfor environments whenskip-installis enabled - The default is now
__token__when prompting for a username for thepublishcommand - Add a new
run_buildermethod to theenvironmentinterface - Bump the minimum supported version of Hatchling to 1.19.0
- Bump the minimum supported version of
clickto 8.0.6
Fixed:
- Fix nushell activation
- Better handling of flat storage directory hierarchies for the
virtualenvironment type - Display useful information when running the
versioncommand outside of a project rather than erroring - Fix the
project metadatacommand by only capturing stdout from the backend - Properly support Google Artifact Registry
- Fix parsing dependencies for environments when warnings are emitted
Changed:
- The
src-layoutproject template option is now enabled by default - Non-critical output now goes to stderr
Added:
- Add
tool.hatch.env.requiresconfiguration to automatically install dependencies for environment and environment collector plugins - Add
customenvironment collector - Improve syncing of dependencies provided through Git direct references
- Add
isolated_data_directoryattribute to the environment interface - Increase the timeout for and add retries to the
indexpublisher - Expand home and environment variables in configured cache and data directories
- Improve readability of exceptions
- Update project templates
- Bump the minimum supported version of Hatchling to 1.14.0
Fixed:
- Fix displaying the version with the
versioncommand when the version is static and build dependencies are unmet - Fix build environments for the
virtualenvironment type when storing within a relative path - Work around System Integrity Protection on macOS when running commands
- Allow setuptools metadata migration for projects without
setup.pyifsetup.cfgis present - Handle additional edge cases for setuptools metadata migration
- Support boolean values for the
config setcommand
Fixed:
- Fix
versioncommand when the version is dynamic and build dependencies are unmet
Fixed:
- Fix getting dynamic metadata from hooks for environments when dependencies are not dynamic
Fixed:
- Computing the path to the user's home directory now gracefully falls back to
~when it cannot be determined
Changed:
- The
run_shell_commandenvironment interface method now accepts arbitrarysubprocess.Popenkeyword arguments. This is not strictly breaking, but will be utilized in upcoming features. - The internal directory structure for storing
virtualenvironments is now more nested. This is not breaking, but any local environments will be created anew.
Added:
- Add
projectcommand group to view details about the project like PEP 621 metadata - Better support for auto-detection of environments by tools like Visual Studio Code now that the storage directory of
virtualenvironments will be flat if Hatch's configuredvirtualenvironment directory resides somewhere within the project root or if it is set to a.virtualenvsdirectory within the user's home directory - Build environments for the
virtualenvironment type are now cached for improved performance - Add
build_environment_existsmethod to the environment interface for implementations that cache the build environment - Add
pathoption to thevirtualenvironment type - Add
--initialize-authflag to theindexpublisher to allow for the saving of authentication information before publishing - Support Bash on Windows for the
shellcommand - The
setuptoolsmigration script no longer modifies the formatting of existingpyproject.tomlconfiguration - Bump the minimum supported version of Hatchling to 1.11.0
Fixed:
- Environments now respect dynamically defined project dependencies
- The
dep hashand alldep showcommands now respect dynamically defined project dependencies - The
env show,dep hash, and alldep showcommands now honor context formatting - Fix matrix variable inclusion filtering of the
runandenv runcommands when there are multiple possible variables - Build environment compatibility is now checked before use
- Decreasing verbosity now has no affect on output that should always be displayed
- Handle more edge cases in the
setuptoolsmigration script - Environments now respect user defined environment variables for context formatting
- Update the scripts in the generated test environment template for new projects to reflect the documentation
- Allow
extra-dependenciesin environment overrides - Depend on
packagingexplicitly rather than relying on it being a transitive dependency of Hatchling
Added:
- The
indexpublisher now recognizes repository-specific options - Add the
--ignore-compatflag to theenv runcommand - Setting the
HATCH_PYTHONenvironment variable toselfwill now force the use of the Python executable Hatch is running on forvirtualenvironment creation
Fixed:
- Fix the
--force-continueflag of theenv runcommand - Handle more edge cases in the
setuptoolsmigration script
Fixed:
- Fix check for updating static versions with the
versioncommand when metadata hooks are in use
Fixed:
- Fix non-detached inheritance disabling for environments
Added:
- The default Python for
virtualenvironments now checks PATH before using the one Hatch is running on - Values for environment
env-varsnow support context formatting - Add
nameoverride for environments to allow for regular expression matching - The
indexpublisher now better supports non-PyPI indices - Add certificate options to the
indexpublisher - Display waiting text when checking dependencies and removing environments
- Display help text the first time the
shellcommand is executed - Update project templates with Python 3.11 and the latest versions of various GitHub Actions
- Add support for Almquist (
ash) shells - Add
hyperlinkas a dependency for better handling of package index URLs - Bump the minimum supported version of
virtualenvto 20.16.2 - Bump the minimum supported version of
tomlkitto 0.11.1
Fixed:
- Acknowledge
extra-dependenciesfor theenv showcommand - Fix locating executables within virtual environments on Debian
- Fix managing the terminal size inside the
shellcommand - Fix default code coverage file omission for the
src-layoutproject template option
Fixed:
- Support
-h/--helpflag for theruncommand
Changed:
- Rename the default publishing plugin from
pypito the more genericindex
Added:
- Support the absence of
pyproject.tomlfiles, as is the case for apps and non-Python projects - Hide scripts that start with an underscore for the
env showcommand by default - Ignoring the exit codes of commands by prefixing with hyphens now works with entire named scripts
- Add a way to require confirmation for publishing
- Add
--force-continueflag to theenv runcommand - Make tracebacks colorful and less verbose
- When shell configuration has not been defined, attempt to use the current shell based on parent processes before resorting to the defaults
- The shell name
pwshis now an alias forpowershell - Remove
atomicwritesdependency - Relax constraint on
userpathdependency - Bump the minimum supported version of Hatchling to 1.4.1
Fixed:
- Keep environments in sync with the dependencies of the selected features
- Use
utf-8for all files generated for new projects - Escape special characters Git may return in the user name when writing generated files for new projects
- Normalize the package name to lowercase in
setuptoolsmigration script - Fix parsing of source distributions during publishing
Fixed:
- Fix handling of top level
data_filesinsetuptoolsmigration script
Changed:
- The
enter_shellenvironment plugin method now accepts an additionalargsparameter
Added:
- Allow context string formatting for environment dependencies
- Add environment context string formatting fields
env_name,env_type,matrix,verbosity, andargs - Support overriding the default arguments used to spawn shells on non-Windows systems
- Bump the minimum supported version of Hatchling to 1.3.0
Fixed:
- Improve
setuptoolsmigration script
Fixed:
- Bump the minimum supported version of Hatchling to 1.2.0
- Update project metadata to reflect support for Python 3.11
Fixed:
- Fix
setuptoolsmigration script for non-Windows systems
Changed:
- In order to simplify the implementation of command execution for environment plugins, the
run_shell_commandsmethod has been replaced by the singularrun_shell_command. A newcommand_contextmethod has been added to more easily satisfy complex use cases. - The
finalize_commandenvironment plugin method has been removed in favor of the newly introduced context formatting functionality.
Added:
- Add context formatting functionality i.e. the ability to insert values into configuration like environment variables and command line arguments
- Any verbosity for command execution will now always display headers, even for single environments
- Every executed command is now displayed when running multiple commands or when verbosity is enabled
- Similar to
make, ignore the exit code of executed commands that start with-(a hyphen) - Add ability for the
--initflag of thenewcommand to automatically migratesetuptoolsconfiguration - Update project metadata to reflect the adoption by PyPA and production stability
This is the first stable release of Hatch v1, a complete rewrite. Enjoy!
"},{"location":"history/hatchling/","title":"Hatchling history","text":"All notable changes to Hatchling will be documented in this file.
The format is based on Keep a Changelog, and this project adheres to Semantic Versioning.
"},{"location":"history/hatchling/#unreleased","title":"Unreleased","text":"Fixed:
- Ignore
manylinux/musllinuxtags for thewheeltarget artifact name when enabling theinfer_tagbuild data
Fixed:
- Add
.venvto the list of directories that cannot be traversed - Output from the core Application utility now writes to stderr
Fixed:
- Maintain file permissions for
shared-scriptsoption/shared_scriptsbuild data of thewheeltarget
Added:
- Add
shared_dataandshared_scriptsbuild data for thewheeltarget
Added:
- Add
shared-scriptsoption for thewheeltarget
Fixed:
- Support recursive optional dependencies
- Set the
packagingdependency version as>=23.2to avoid its URL validation which can conflict with context formatting
Fixed:
- Fix reading metadata from source distributions when fields are dynamic but not part of core metadata like entry points
Fixed:
- Only read source distribution metadata for fields that are explicitly defined as dynamic
Fixed:
- Fix the
custombuild hook when using dynamic dependencies
Fixed:
- Fix regression when loading metadata from source distributions
- Fix metadata hooks when building wheels from source distributions
Fixed:
- Update the default version of core metadata to 2.3
Deprecated:
- The
appbuild target has been renamed tobinaryto reduce ambiguity with the name of an upcoming feature. The former name will still be usable for several minor releases.
Added:
- Metadata for the
wheeltarget now defaults to thePKG-INFOmetadata within source distributions - Add
dependenciesmethod to the build hook interface so that hooks can themselves dynamically define dependencies - Update the default version of core metadata to 2.2
- Update SPDX license information to version 3.23
- Improve error message for when the default heuristics for wheel file inclusion fail
Fixed:
- Properly support core metadata version 2.2
- Remove
editablesas a direct dependency - Fix default wheel tag when the supported Python version declaration is strict
- Load VCS ignore patterns first so that whitelisted patterns can be excluded by project configuration
- Don't consider VCS ignore files that are outside of the VCS boundary
- The
sdistbuild target now gracefully ignores UNIX socket files - Begin ignoring certain files ubiquitously, like
.DS_Storeon macOS
Fixed:
- Fix loading of local plugins to account for newly released versions of a dependency
Added:
- Add
parentcontext modifier for path fields
Added:
- Add
bypass-selectionoption to thewheelbuild target to allow for empty (metadata-only) wheels
Fixed:
- Fix regression in 1.19.1 that allowed
excludeto count toward inclusion selection, thus bypassing the default inclusion selection heuristics - Fix writing optional dependency core metadata in situations where there are multiple environment markers
Fixed:
- Add better error message when the
wheelbuild target cannot determine what to ship - Consider forced inclusion patterns and build-time artifacts as file selection since some build hooks generate the entire wheel contents without user configuration
Changed:
- An error will now be raised if a force-included path does not exist
- An error will now be raised for the
wheelbuild target if no file selection options are defined
Added:
- Officially support Python 3.12
- Allow using an empty string for the
sourcesoption to add a prefix to distribution paths
Fixed:
- Properly handle non-zero version epoch for the
standardversion scheme - Fix the
wheelbuild target for case insensitive file systems when the project metadata name does not match the directory name on disk - The
appbuild target no longer has suppressed output - Prevent duplicate paths when projects require the
sourcesoption while build hooks overwrite included paths - Properly escape spaces for URI context formatting
Changed:
- Drop support for Python 3.7
Added:
- Update the list of directories that are always excluded for builds
Fixed:
- Fix dev mode when the project has symlinks and file inclusion is defined with the
packagesoronly-includeoptions - Change the name of generated PTH files for dev mode so they come first lexicographically and therefore load first
Added:
- The
appbuild target now embeds the project version in the name of binaries
Fixed:
- Fix determining the built executable path for the
appbuild target option when using a local copy of PyApp when there is an explicit target triple set
Added:
- Add
appbuild target option to build using a local copy of the PyApp repository
Added:
- Add
appbuild target
Fixed:
- Fix internal archive root naming for the
sdisttarget whenstrict-namingis disabled to match the file name in order to support the expectation of some frontends
Added:
- Add
trove-classifiersas a dependency
Fixed:
- Properly normalize metadata descriptions that contain line breaks
Added:
- Update the set of known trove classifiers to version 2023.2.8
Fixed:
- Add
macos-max-compatoption to thewheeltarget that is enabled by default to support the latest version 22.0 of thepackaginglibrary
Fixed:
- Fix minor regression in the PEP 517/660 function signatures that was discovered by Fedora
Added:
- Improve readability of exceptions
- Add
extra_metadatabuild data to thewheeltarget - Retroactively support
License-Expressioncore metadata starting at version 2.1 - Add more type hints
- Update the set of known trove classifiers to version 2022.12.22
- Update SPDX license information to version 3.19
- Store Hatchling's metadata in
pyproject.toml
Fixed:
- Acknowledge the
ARCHFLAGSenvironment variable on macOS for thewheeltarget when build hooks set theinfer_tagbuild data totrue - Fix dependency checking when encountering broken distributions
- Fix the
support-legacyoption for thesdisttarget when using a src-layout project structure - Remove unnecessary encoding declaration in the default template for the
versionbuild hook
Fixed:
- Fix default file selection behavior of the
wheeltarget when there is a single top-level module
Added:
- Add
envversion source to retrieve the version from an environment variable - Add
validate-bumpoption to thestandardversion scheme
Fixed:
- Use proper CSV formatting for the
RECORDmetadata file of thewheeltarget to avoid warnings during installation bypipif, for example, file names contain commas - Fix installations with pip for build hooks that modify runtime dependencies
- Decreasing verbosity now has no affect on output that should always be displayed
Added:
- Add the following to the list of directories that cannot be traversed:
__pypackages__,.hg,.hatch,.tox,.nox - Add deprecated option to allow ambiguous features
Fixed:
- Improve tracking of dynamic metadata
- Fix core metadata for entries in
project.optional-dependenciesthat use direct references
Changed:
- File pattern matching now more closely resembles Git's behavior
Added:
- Implement a minimal version of
prepare_metadata_for_build_wheelandprepare_metadata_for_build_editablefor non-frontend tools that only need to inspect a project's metadata - Add
metadatacommand to view PEP 621 project metadata - Improve error messages for SPDX license errors
- Retroactively support
License-Filefor core metadata starting at version 2.1 - Bump the minimum supported version of
pathspecto 0.10.1
Fixed:
- Allow the valid non-SPDX
licensevaluesLicenseRef-Public-DomainandLicenseRef-Proprietary - Show the help text of the CLI when no subcommand is selected
Fixed:
- Fix default file inclusion for
wheelbuild targets when both the project name and package directory name are not normalized
Added:
- Add
get_known_classifiersmethod to metadata hooks
Fixed:
- Fix check for updating static versions with the
versioncommand when metadata hooks are in use
Fixed:
- Fix the value of the
relative_pathattribute of included files, that some build plugins may use, when selecting explicit paths
Added:
- Add
require-runtime-featuresoption for builders and build hooks - Check for unknown trove classifiers
- Update SPDX license information to version 3.18
Fixed:
- Add better error message for
wheeltarget dev mode installations that define path rewrites with thesourcesoption - Note the
allow-direct-referencesoption in the relevant error messages
Changed:
- When no build targets are specified on the command line, now default to
sdistandwheeltargets rather than what happens to be defined in config - The
codeversion source now only supports files with known extensions - Global build hooks now run before target-specific build hooks to better match expected behavior
Added:
- The
codeversion source now supports loading extension modules - Add
search-pathsoption for thecodeversion source
Fixed:
- Fix removing
sourcesusing an empty string value in the mapping - The
strict-namingoption now also applies to the metadata directory ofwheeltargets
Added:
- Support the final draft of PEP 639
- Add
strict-namingoption forsdistandwheeltargets
Fixed:
- Project names are now stored in
sdistandwheeltarget core metadata exactly as defined inpyproject.tomlwithout normalization to allow control of how PyPI displays them
Fixed:
- Fix forced inclusion of important files like licenses for
sdisttargets when using the explicit selection options - Don't sort project URL metadata so that the rendered order on PyPI can be controlled
Changed:
- The
packagesoption uses the newonly-includeoption to provide targeted inclusion, since that is desired most of the time. You can retain the old behavior by using theincludeandsourcesoptions together.
Added:
- Support PEP 561 type hinting
- Add
versionbuild hook - Add
only-includeoption - The
editableversion ofwheeltargets now respects theforce-includeoption by default - The
force-includeoption now supports path rewriting with thesourcesoption - The
wheeltargetshared-dataandextra-metadataoptions now respect file selection options - The
wheeltarget now auto-detects single module layouts - Improve performance by never entering directories that are guaranteed to be undesirable like
__pycache__rather than excluding individual files within - Update SPDX license information to version 3.17
Fixed:
- Don't write empty entry points file for
wheeltargets if there are no entry points defined - Allow metadata hooks to set the
versionin all cases - Prevent duplicate file entries from inclusion when using the
force-includeoption
Fixed:
- Better populate global variables for the
codeversion source
Removed:
- Remove unused global
argscontext string formatting field
Added:
- Improve error messages for the
envcontext string formatting field
Fixed:
- Fix
uricontext string formatting modifier on Windows
Added:
- Allow context formatting for
project.dependenciesandproject.optional-dependencies
Added:
- Add
uriandrealcontext string formatting modifiers for file system paths
Changed:
- Drop support for Python 2
Added:
- Improve error messaging for invalid versions
- Update project metadata to reflect support for Python 3.11
Fixed:
- Fix support for Windows on Python 2 by removing its support for symlinks
Added:
- Add
skip-excluded-dirsbuild option - Allow build data to add additional project dependencies for
wheelandsdistbuild targets - Add
force_include_editablebuild data for thewheelbuild target - Add
build_hooksbuild data - Add support for Mercurial's
.hgignorefiles when using glob syntax - Update project metadata to reflect the adoption by PyPA
Fixed:
- Properly use underscores for the name of
force_includebuild data - No longer greedily skip excluded directories by default
This is the initial public release of the Hatchling build system. Support for Python 2 will be dropped in version 1.
"},{"location":"how-to/config/dynamic-metadata/","title":"How to configure custom dynamic metadata","text":"If you have project metadata that is not appropriate for static entry into
pyproject.tomlyou will need to provide a custom metadata hook to apply such data during builds.Alternatives
Dynamic metadata is a way to have a single source of truth that will be available at build time and at run time. Another way to achieve that is to enter the build data statically and then look up the same information dynamically in the program or package, using importlib.metadata.
If the version field is the only metadata of concern, Hatchling provides a few built-in ways such as the
"},{"location":"how-to/config/dynamic-metadata/#update-project-metadata","title":"Update project metadata","text":"regexversion source and also third-party plugins. The approach here will also work, but is more complex.Change the
[project]section ofpyproject.toml:- Define the dynamic field as an array of all the fields you will set dynamically e.g.
dynamic = [\"version\", \"license\", \"authors\", \"maintainers\"] - If any of those fields have static definitions in
pyproject.toml, delete those definitions. It is verboten to define a field statically and dynamically.
Add a section to trigger loading of dynamic metadata plugins:
[tool.hatch.metadata.hooks.custom]. Use exactly that name, regardless of the name of the class you will use or itsPLUGIN_NAME. There doesn't need to be anything in the section.If your plugin requires additional third-party packages to do its work, add them to the
"},{"location":"how-to/config/dynamic-metadata/#implement-hook","title":"Implement hook","text":"requiresarray in the[build-system]section ofpyproject.toml.The dynamic lookup must happen in a custom plugin that you write. The default expectation is that it is in a
hatch_build.pyhatch_build.pyfile at the root of the project. SubclassMetadataHookInterfaceand implementupdate(); for example, here's plugin that reads metadata from a JSON file:import json\nimport os\n\nfrom hatchling.metadata.plugin.interface import MetadataHookInterface\n\n\nclass JSONMetaDataHook(MetadataHookInterface):\n def update(self, metadata):\n src_file = os.path.join(self.root, \"gnumeric\", \".constants.json\")\n with open(src_file) as src:\n constants = json.load(src)\n metadata[\"version\"] = constants[\"__version__\"]\n metadata[\"license\"] = constants[\"__license__\"]\n metadata[\"authors\"] = [\n {\"name\": constants[\"__author__\"], \"email\": constants[\"__author_email__\"]},\n ]\n- You must import the MetadataHookInterface to subclass it.
- Do your operations inside the
updatemethod. metadatarefers to project metadata.- When writing to metadata, use
listfor TOML arrays. Note that if a list is expected, it is required even if there is a single element. - Use
dictfor TOML tables e.g.authors.
If you want to store the hook in a different location, set the
pyproject.toml hatch.tomlpathoption:[tool.hatch.metadata.hooks.custom]\npath = \"some/where.py\"\n
"},{"location":"how-to/environment/dependency-resolution/","title":"How to configure dependency resolution","text":"[metadata.hooks.custom]\npath = \"some/where.py\"\nMost Hatch environment types, like the default virtual, simply use pip to install dependencies. Therefore, you can use the standard environment variables that influence
pip's behavior.Here's an example of setting up the default environment to look at 2 private indices (using context formatting for authentication) before finally falling back to PyPI:
pyproject.toml hatch.toml[tool.hatch.envs.default.env-vars]\nPIP_INDEX_URL = \"https://token:{env:GITLAB_API_TOKEN}@gitlab.com/api/v4/groups/<group1_path>/-/packages/pypi/simple/\"\nPIP_EXTRA_INDEX_URL = \"https://token:{env:GITLAB_API_TOKEN}@gitlab.com/api/v4/groups/<group2_path>/-/packages/pypi/simple/ https://pypi.org/simple/\"\n
"},{"location":"how-to/environment/dependency-resolution/#uv","title":"UV","text":"[envs.default.env-vars]\nPIP_INDEX_URL = \"https://token:{env:GITLAB_API_TOKEN}@gitlab.com/api/v4/groups/<group1_path>/-/packages/pypi/simple/\"\nPIP_EXTRA_INDEX_URL = \"https://token:{env:GITLAB_API_TOKEN}@gitlab.com/api/v4/groups/<group2_path>/-/packages/pypi/simple/ https://pypi.org/simple/\"\nIf you're using UV, a different set of environment variables are available to configure its behavior. The previous example would look like this instead:
pyproject.toml hatch.toml[tool.hatch.envs.default.env-vars]\nUV_EXTRA_INDEX_URL = \"https://token:{env:GITLAB_API_TOKEN}@gitlab.com/api/v4/groups/<group1_path>/-/packages/pypi/simple/\"\nUV_INDEX_URL = \"https://token:{env:GITLAB_API_TOKEN}@gitlab.com/api/v4/groups/<group2_path>/-/packages/pypi/simple/ https://pypi.org/simple/\"\n[envs.default.env-vars]\nUV_EXTRA_INDEX_URL = \"https://token:{env:GITLAB_API_TOKEN}@gitlab.com/api/v4/groups/<group1_path>/-/packages/pypi/simple/\"\nUV_INDEX_URL = \"https://token:{env:GITLAB_API_TOKEN}@gitlab.com/api/v4/groups/<group2_path>/-/packages/pypi/simple/ https://pypi.org/simple/\"\nTip
If you need precise control over the prioritization of package indices, then using UV is recommended because
"},{"location":"how-to/environment/select-installer/","title":"How to select the installer","text":""},{"location":"how-to/environment/select-installer/#enabling-uv","title":"Enabling UV","text":"piphas no index order guarantee.The virtual environment type by default uses virtualenv for virtual environment creation and pip to install dependencies. You can speed up environment creation and dependency resolution by using UV instead of both of those tools.
caveat
UV is under active development and may not work for all dependencies.
To do so, set the
pyproject.toml hatch.tomlinstalleroption touv. For example, if you wanted to enable this functionality for the default environment, you could set the following:[tool.hatch.envs.default]\ninstaller = \"uv\"\n[envs.default]\ninstaller = \"uv\"\nTip
All environments that enable UV will have the path to UV available as the
"},{"location":"how-to/environment/select-installer/#configuring-the-version","title":"Configuring the version","text":"HATCH_UVenvironment variable.The UV that is shared by all environments uses a specific version range that is known to work with Hatch. If you want to use a different version, you can override the dependencies for the internal
pyproject.toml hatch.tomlhatch-uvenvironment:[tool.hatch.envs.hatch-uv]\ndependencies = [\n \"uv>9000\",\n]\n
"},{"location":"how-to/environment/select-installer/#externally-managed","title":"Externally managed","text":"[envs.hatch-uv]\ndependencies = [\n \"uv>9000\",\n]\nIf you want to manage UV yourself, you can expose it to Hatch by setting the
"},{"location":"how-to/environment/select-installer/#installer-script-alias","title":"Installer script alias","text":"HATCH_ENV_TYPE_VIRTUAL_UV_PATHenvironment variable which should be the absolute path to a UV binary for Hatch to use instead. This implicitly enables UV.If you have scripts or commands that call
pyproject.toml hatch.tomlpip, it may be useful to alias theuv pipcommand topipso that you can use the same commands for both methods of configuration and retain your muscle memory. The following is an example of a matrix that conditionally enables UV and sets the alias:[[tool.hatch.envs.example.matrix]]\ntool = [\"uv\", \"pip\"]\n\n[tool.hatch.envs.example.overrides]\nmatrix.tool.installer = { value = \"{matrix:tool}\" }\nmatrix.tool.scripts = [\n { key = \"pip\", value = \"{env:HATCH_UV} pip {args}\", if = [\"uv\"] },\n]\n[[envs.example.matrix]]\ntool = [\"uv\", \"pip\"]\n\n[envs.example.overrides]\nmatrix.tool.installer = { value = \"{matrix:tool}\" }\nmatrix.tool.scripts = [\n { key = \"pip\", value = \"{env:HATCH_UV} pip {args}\", if = [\"uv\"] },\n]\nAnother common use case is to expose UV to all test environments. In this case, you often wouldn't want to modify the
pyproject.toml hatch.tomlscriptsmapping directly but rather add an extra script:[tool.hatch.envs.hatch-test.extra-scripts]\npip = \"{env:HATCH_UV} pip {args}\"\n
"},{"location":"how-to/integrate/vscode/","title":"How to use Hatch environments from Visual Studio Code","text":"[envs.hatch-test.extra-scripts]\npip = \"{env:HATCH_UV} pip {args}\"\nVisual Studio Code announced support for Hatch environment discovery in
vscode-python's 2024.4 release.For it to work, you should install Hatch globally. If you used the GUI installers on Windows or macOS, or your system package manager on e.g. Arch Linux or Fedora, this should be taken care of.
Setting up PATHIf you installed Hatch with pipx rather than system-wide, you might need to add
$HOME/.local/binto your PATH environment variable for your graphical session, not just your terminal. Check like this:$ pgrep bin/code # or some other graphical application\n1234\n$ cat /proc/1234/environ | tr '\\0' '\\n' | grep -E '^PATH='\nPATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin\nIf the directory is not in there, you need to add it in your session startup script, in a way that depends on your desktop environment:
- KDE Plasma
- GNOME
-
Make Hatch install the project and its dependencies to an environment using the
env createcommand. -
Select an interpreter using the Python: Select Interpreter command:
-
You should now be able to use the environment. For example, if you have the
python.terminal.activateEnvironmentsetting set totrueand you open a new terminal, the environment should be activated. Alternatively, you could press the \"play\" button to run a file in the environment:
All reports regarding unexpected behavior should be generated with the
self reportcommand:$ hatch self report\nBy default, this will open a new tab in your default browser with pre-populated information about your environment.
If Hatch is not installed alongside a web browser, you may also pass the
--no-open/-ncommand which will output the URL with correct parameters for copying elsewhere:
"},{"location":"how-to/plugins/testing-builds/","title":"Testing build plugins","text":"$ hatch self report -n\nhttps://github.com/pypa/hatch/issues/new?body=%23%23+Current+behavior%0A%3C%21--+A+clear+and+concise+description+of+the+behavior.+--%3E%0A%0A%23%23+Expected+behavior%0A%3C%21--+A+clear+and+concise+description+of+what+you+expected+to+happen.+--%3E%0A%0A%23%23+Additional+context%0A%3C%21--+Add+any+other+context+about+the+problem+here.+If+applicable%2C+add+screenshots+to+help+explain.+--%3E%0A%0A%23%23+Debug%0A%0A%23%23%23+Installation%0A%0A-+Source%3A+pip%0A-+Version%3A+1.9.2.dev5%0A-+Platform%3A+Windows%0A-+Python+version%3A%0A++++%60%60%60%0A++++3.11.1+%28tags%2Fv3.11.1%3Aa7a450f%2C+Dec++6+2022%2C+19%3A58%3A39%29+%5BMSC+v.1934+64+bit+%28AMD64%29%5D%0A++++%60%60%60%0A%0A%23%23%23+Configuration%0A%0A%60%60%60toml%0Amode+%3D+%22local%22%0Ashell+%3D+%22nu%22%0A%60%60%60%0A\nFor testing Hatchling plugins, you'll usually want to generate a project to execute builds as a real user would. For example, as a minimal pytest fixture:
from pathlib import Path\n\nimport pytest\n\n\n@pytest.fixture\ndef new_project(tmp_path):\n project_dir = tmp_path / 'my-app'\n project_dir.mkdir()\n\n project_file = project_dir / 'pyproject.toml'\n project_file.write_text(\n f\"\"\"\\\n[build-system]\nrequires = [\"hatchling\", \"hatch-plugin-name @ {Path.cwd().as_uri()}\"]\nbuild-backend = \"hatchling.build\"\n\n[project]\nname = \"my-app\"\nversion = \"0.1.0\"\n\"\"\",\n encoding='utf-8',\n )\n ...\nThe issue with this is that after the first test session, the project will be forever cached by pip based on the file path. Therefore, subsequent tests runs will never use updated code.
To invalidate the cache, copy your code to a new path for every test session:
import shutil\nfrom pathlib import Path\nfrom tempfile import TemporaryDirectory\n\nimport pytest\n\n\n@pytest.fixture(scope='session')\ndef plugin_dir():\n with TemporaryDirectory() as d:\n directory = Path(d, 'plugin')\n shutil.copytree(\n Path.cwd(), directory, ignore=shutil.ignore_patterns('.git')\n )\n\n yield directory.resolve()\n\n\n@pytest.fixture\ndef new_project(tmp_path, plugin_dir):\n project_dir = tmp_path / 'my-app'\n project_dir.mkdir()\n\n project_file = project_dir / 'pyproject.toml'\n project_file.write_text(\n f\"\"\"\\\n[build-system]\nrequires = [\"hatchling\", \"hatch-plugin-name @ {plugin_dir.as_uri()}\"]\nbuild-backend = \"hatchling.build\"\n\n[project]\nname = \"my-app\"\nversion = \"0.1.0\"\n\"\"\",\n encoding='utf-8',\n )\n ...\nNote
This example chooses to ignore copying
"},{"location":"how-to/publish/auth/","title":"How to authenticate for index publishing","text":".gitfor performance reasons. You may want to ignore more patterns, or copy only specific paths like this plugin does.The username is derived from the following sources, in order of precedence:
- The
--user/-ucli option. - The
HATCH_INDEX_USERenvironment variable. - The
repostables. - The
~/.pypircfile. - The input to an interactive prompt.
As a fallback the value
__token__is applied.The password is looked up in these:
- The
~/.pypircfile if the username was provided by it. - The
--auth/-acli option. - The
HATCH_INDEX_AUTHenvironment variable. - The
repostables. - A variety of OS-level credentials services backed by keyring.
- The input to an interactive prompt.
If interactively provided credentials were used, the username will be stored in Hatch's cache and the password stored in the available keyring backed credentials stores.
For automated releasing to PyPI, it is recommended to use \"Trusted Publishing\" with OIDC (e.g. PyPA's
"},{"location":"how-to/publish/repo/","title":"How to configure repositories for index publishing","text":"pypi-publishGitHub Action) or per-project API tokens.You can select the repository with which to upload using the
-r/--repooption or by setting theHATCH_INDEX_REPOenvironment variable.Rather than specifying the full URL of a repository, you can use a named repository from a
config.tomlpublish.index.repostable defined in Hatch's config file:[publish.index.repos.private]\nurl = \"...\"\n...\nThe following repository names are reserved by Hatch and cannot be overridden:
Name Repositorymainhttps://upload.pypi.org/legacy/testhttps://test.pypi.org/legacy/The
"},{"location":"how-to/python/custom/","title":"How to use custom Python distributions","text":"mainrepository is used by default.The built-in Python management capabilities offer full support for using custom distributions.
"},{"location":"how-to/python/custom/#configuration","title":"Configuration","text":"Configuring custom Python distributions is done entirely through three environment variables that must all be defined, for each desired distribution. In the following sections, the placeholder
"},{"location":"how-to/python/custom/#source","title":"Source","text":"<NAME>is the uppercased version of the distribution name with periods replaced by underscores e.g.pypy3.10would becomePYPY3_10.The
HATCH_PYTHON_CUSTOM_SOURCE_<NAME>variable is the URL to the distribution's archive. The value must end with the archive's real file extension, which is used to determine the extraction method.The following extensions are supported:
Extensions Description.tar.bz2.bz2
.tar.gz.tgz
.tar.zst.tar.zstd
.zip
The
"},{"location":"how-to/python/custom/#version","title":"Version","text":"HATCH_PYTHON_CUSTOM_PATH_<NAME>variable is the path to the Python interpreter within the archive. This path is relative to the root of the archive and must be a Unix-style path, even on Windows.The
"},{"location":"how-to/run/python-scripts/","title":"How to run Python scripts","text":"HATCH_PYTHON_CUSTOM_VERSION_<NAME>variable is the version of the distribution. This value is used to determine whether updates are required and is displayed in the output of thepython showcommand.The
runcommand supports executing Python scripts with inline metadata, such that a dedicated environment is automatically created with the required dependencies and with the correct version of Python.A script metadata block is a comment block that starts with
# /// scriptand ends with# ///. Every line between those two lines must be a comment line that starts with#and contains a TOML document when the comment characters are removed.The top-level fields are:
dependencies: A list of strings that specifies the runtime dependencies of the script. Each entry must be a valid dependency specifier.requires-python: A string that specifies the Python version(s) with which the script is compatible. The value of this field must be a valid version specifier.
The following is an example of Python script with a valid metadata block:
script.py# /// script\n# requires-python = \">=3.11\"\n# dependencies = [\n# \"httpx\",\n# \"rich\",\n# ]\n# ///\n\nimport httpx\nfrom rich.pretty import pprint\n\nresp = httpx.get(\"https://peps.python.org/api/peps.json\")\ndata = resp.json()\npprint([(k, v[\"title\"]) for k, v in data.items()][:10])\nRun it directly:
$ hatch run /path/to/script.py\nCreating environment: SyB4bPbL\nChecking dependencies\nSyncing dependencies\n[\n\u2502 ('1', 'PEP Purpose and Guidelines'),\n\u2502 ('2', 'Procedure for Adding New Modules'),\n\u2502 ('3', 'Guidelines for Handling Bug Reports'),\n\u2502 ('4', 'Deprecation of Standard Modules'),\n\u2502 ('5', 'Guidelines for Language Evolution'),\n\u2502 ('6', 'Bug Fix Releases'),\n\u2502 ('7', 'Style Guide for C Code'),\n\u2502 ('8', 'Style Guide for Python Code'),\n\u2502 ('9', 'Sample Plaintext PEP Template'),\n\u2502 ('10', 'Voting Guidelines')\n]\nnotes
- The informational text in this example is only temporarily shown in your terminal on the first run.
- Although the environment name is based on the script's absolute path, the command line argument does not have to be.
You may use the
script.py[tool.hatch]table directly to control the script's environment. For example, if you wanted to disable UV (which is enabled by default for scripts), you could add the following:
"},{"location":"how-to/static-analysis/behavior/","title":"Customize static analysis behavior","text":"# /// script\n# ...\n# [tool.hatch]\n# installer = \"pip\"\n# ///\nYou can fully alter the static analysis performed by the
pyproject.toml hatch.tomlfmtcommand by modifying the reserved environment namedhatch-static-analysis. For example, you could define the following if you wanted to replace the default behavior with a mix of Black, isort and basic flake8:[tool.hatch.envs.hatch-static-analysis]\ndependencies = [\"black\", \"flake8\", \"isort\"]\n\n[tool.hatch.envs.hatch-static-analysis.scripts]\nformat-check = [\n \"black --check --diff {args:.}\",\n \"isort --check-only --diff {args:.}\",\n]\nformat-fix = [\n \"isort {args:.}\",\n \"black {args:.}\",\n]\nlint-check = \"flake8 {args:.}\"\nlint-fix = \"lint-check\"\n[envs.hatch-static-analysis]\ndependencies = [\"black\", \"flake8\", \"isort\"]\n\n[envs.hatch-static-analysis.scripts]\nformat-check = [\n \"black --check --diff {args:.}\",\n \"isort --check-only --diff {args:.}\",\n]\nformat-fix = [\n \"isort {args:.}\",\n \"black {args:.}\",\n]\nlint-check = \"flake8 {args:.}\"\nlint-fix = \"lint-check\"\nThe
Command Expanded scriptsformat-*scripts correspond to the--formatter/-fflag while thelint-*scripts correspond to the--linter/-lflag. The*-fixscripts run by default while the*-checkscripts correspond to the--checkflag. Based on this example, the following shows how the various scripts influence behavior:hatch fmtflake8 .isort .black .
hatch fmt src testsflake8 src testsisort src testsblack src tests
hatch fmt -fisort .black .
hatch fmt -lflake8 .
hatch fmt --checkflake8 .black --check --diff .isort --check-only --diff .
hatch fmt --check -fblack --check --diff .isort --check-only --diff .
hatch fmt --check -lflake8 .
- Ofek Lev
- Amjith Ramanujam
- Arnaud Crowther
- Chaojie
- Chris Warrick
- Lum\u00edr 'Frenzy' Balhar
- Ofek Lev
- Olga Matoula
- Philip Blair
- Robert Rosca
Q: What is the risk of lock-in?
A: Not much! Other than the plugin system, everything uses Python's established standards by default. Project metadata is based entirely on the standard, the build system is compatible with PEP 517/PEP 660, versioning uses the scheme specified by PEP 440, dependencies are defined with PEP 508 strings, and environments use virtualenv.
Q: Must one use all features?
A: No, all features are optional! You can use just the build system, publish wheels and source distributions that were built by other tools, only use the environment management, etc.
"},{"location":"meta/faq/#libraries-vs-applications","title":"Libraries vs applications","text":"Q: Are workflows for both libraries and applications supported?
A: Yes, mostly! Applications can utilize environment management just like libraries, and plugins can be used to build projects in arbitrary formats or publish artifacts to arbitrary destinations.
The only caveat is that currently there is no support for re-creating an environment given a set of dependencies in a reproducible manner. Although a standard lock file format may be far off since PEP 665 was rejected, resolving capabilities are coming to pip. When that is stabilized, Hatch will add locking functionality and dedicated documentation for managing applications.
"},{"location":"meta/faq/#tool-migration","title":"Tool migration","text":"Q: How to migrate to Hatch?
"},{"location":"meta/faq/#build-system","title":"Build system","text":"SetuptoolsHatch setup.py MANIFEST.inimport os\nfrom io import open\n\nfrom setuptools import find_packages, setup\n\nabout = {}\nwith open(os.path.join('src', 'foo', '__about__.py'), 'r', 'utf-8') as f:\n exec(f.read(), about)\n\nwith open('README.md', 'r', 'utf-8') as f:\n readme = f.read()\n\nsetup(\n # Metadata\n name='foo',\n version=about['__version__'],\n description='...',\n long_description=readme,\n long_description_content_type='text/markdown',\n author='...',\n author_email='...',\n project_urls={\n 'Documentation': '...',\n 'Source': '...',\n },\n classifiers=[\n '...',\n ],\n keywords=[\n '...',\n ],\n python_requires='>=3.8',\n install_requires=[\n '...',\n ],\n extras_require={\n 'feature': ['...'],\n },\n\n # Packaging\n packages=find_packages(where='src'),\n package_dir={'': 'src'},\n package_data={\n 'foo': ['py.typed'],\n },\n zip_safe=False,\n entry_points={\n 'console_scripts': [\n 'foo = foo.cli:main',\n ],\n },\n)\n
pyproject.tomlgraft tests\n\nglobal-exclude *.py[cod] __pycache__\n
"},{"location":"meta/faq/#environments","title":"Environments","text":"ToxHatch[build-system]\nrequires = [\"hatchling\"]\nbuild-backend = \"hatchling.build\"\n\n[project]\nname = \"foo\"\ndescription = \"...\"\nreadme = \"README.md\"\nauthors = [\n { name = \"...\", email = \"...\" },\n]\nclassifiers = [\n \"...\",\n]\nkeywords = [\n \"...\",\n]\nrequires-python = \">=3.8\"\ndependencies = [\n \"...\",\n]\ndynamic = [\"version\"]\n\n[project.urls]\nDocumentation = \"...\"\nSource = \"...\"\n\n[project.optional-dependencies]\nfeature = [\"...\"]\n\n[project.scripts]\nfoo = \"foo.cli:main\"\n\n[tool.hatch.version]\npath = \"src/foo/__about__.py\"\n\n[tool.hatch.build.targets.sdist]\ninclude = [\n \"/src\",\n \"/tests\",\n]\nInvocation:
tox.initox\n[tox]\nenvlist =\n py{38,39}-{42,3.14}\n py{39,310}-{9000}-{foo,bar}\n\n[testenv]\nusedevelop = true\ndeps =\n coverage[toml]\n pytest\n pytest-cov\n foo: cryptography\ncommands =\n pytest --cov-report=term-missing --cov-config=pyproject.toml --cov=pkg --cov=tests {posargs}\nsetenv =\n 3.14: PRODUCT_VERSION=3.14\n 42: PRODUCT_VERSION=42\n 9000: PRODUCT_VERSION=9000\n {foo,bar}: EXPERIMENTAL=true\nInvocation:
pyproject.toml hatch.tomlhatch run test\n[tool.hatch.envs.default]\ndependencies = [\n \"coverage[toml]\",\n \"pytest\",\n \"pytest-cov\",\n]\n\n[tool.hatch.envs.default.scripts]\ntest = 'pytest --cov-report=term-missing --cov-config=pyproject.toml --cov=pkg --cov=tests'\n\n[tool.hatch.envs.default.overrides]\nmatrix.version.env-vars = \"PRODUCT_VERSION\"\nmatrix.feature.env-vars = \"EXPERIMENTAL=true\"\nmatrix.feature.dependencies = [\n { value = \"cryptography\", if = [\"foo\"] },\n]\n\n[[tool.hatch.envs.default.matrix]]\npython = [\"3.8\", \"3.9\"]\nversion = [\"42\", \"3.14\"]\n\n[[tool.hatch.envs.default.matrix]]\npython = [\"3.9\", \"3.10\"]\nversion = [\"9000\"]\nfeature = [\"foo\", \"bar\"]\n
"},{"location":"meta/faq/#fast-cli","title":"Fast CLI?","text":"[envs.default]\ndependencies = [\n \"coverage[toml]\",\n \"pytest\",\n \"pytest-cov\",\n]\n\n[envs.default.scripts]\ntest = 'pytest --cov-report=term-missing --cov-config=pyproject.toml --cov=pkg --cov=tests'\n\n[envs.default.overrides]\nmatrix.version.env-vars = \"PRODUCT_VERSION\"\nmatrix.feature.env-vars = \"EXPERIMENTAL=true\"\nmatrix.feature.dependencies = [\n { value = \"cryptography\", if = [\"foo\"] },\n]\n\n[[envs.default.matrix]]\npython = [\"3.8\", \"3.9\"]\nversion = [\"42\", \"3.14\"]\n\n[[envs.default.matrix]]\npython = [\"3.9\", \"3.10\"]\nversion = [\"9000\"]\nfeature = [\"foo\", \"bar\"]\nThe claim about being faster than other tools is based on timings that are always checked in CI.
Hatch achieves this by using lazy imports, lazily performing computation manually and with functools.cached_property, using hacks like
"},{"location":"plugins/about/","title":"Plugins","text":"not not ...instead ofbool(...), etc.Hatch utilizes pluggy for its plugin functionality.
"},{"location":"plugins/about/#overview","title":"Overview","text":"All plugins provide registration hooks that return one or more classes that inherit from a particular type interface.
Each registration hook must be decorated by Hatch's hook marker. For example, if you wanted to create a new kind of environment you could do:
hooks.pyfrom hatchling.plugin import hookimpl\n\nfrom .plugin import SpecialEnvironment\n\n\n@hookimpl\ndef hatch_register_environment():\n return SpecialEnvironment\nThe hooks can return a single class or a list of classes.
Every class must define an attribute called
plugin.pyPLUGIN_NAMEthat users will select when they wish to use the plugin. So in the example above, the class might be defined like:
"},{"location":"plugins/about/#project-configuration","title":"Project configuration","text":""},{"location":"plugins/about/#naming","title":"Naming","text":"...\nclass SpecialEnvironment(...):\n PLUGIN_NAME = 'special'\n ...\nIt is recommended that plugin project names are prefixed with
pyproject.tomlhatch-. For example, if you wanted to make a plugin that provides some functionality for a product namedfooyou might do:
"},{"location":"plugins/about/#discovery","title":"Discovery","text":"[project]\nname = \"hatch-foo\"\nYou'll need to define your project as a Python plugin for Hatch:
pyproject.toml[project.entry-points.hatch]\nfoo = \"pkg.hooks\"\nThe name of the plugin should be the project name (excluding any
"},{"location":"plugins/about/#classifier","title":"Classifier","text":"hatch-prefix) and the path should represent the module that contains the registration hooks.Add
pyproject.tomlFramework :: Hatchto your project's classifiers to make it easy to search for Hatch plugins:
"},{"location":"plugins/about/#types","title":"Types","text":""},{"location":"plugins/about/#hatchling","title":"Hatchling","text":"[project]\nclassifiers = [\n ...\n \"Framework :: Hatch\",\n ...\n]\nThese are all involved in building projects and therefore any defined dependencies are automatically installed in each build environment.
- Builder
- Build hook
- Metadata hook
- Version source
- Version scheme
These must be installed in the same environment as Hatch itself.
- Environment
- Environment collector
- Publisher
hatchling.builders.utils.get_reproducible_timestamp() -> int","text":"Returns an
intderived from theSOURCE_DATE_EPOCHenvironment variable; see https://reproducible-builds.org/specs/source-date-epoch/.The default value will always be:
Source code in1580601600backend/src/hatchling/builders/utils.py
"},{"location":"plugins/utilities/#hatchling.builders.config.BuilderConfig","title":"def get_reproducible_timestamp() -> int:\n \"\"\"\n Returns an `int` derived from the `SOURCE_DATE_EPOCH` environment variable; see\n https://reproducible-builds.org/specs/source-date-epoch/.\n\n The default value will always be: `1580601600`\n \"\"\"\n return int(os.environ.get('SOURCE_DATE_EPOCH', '1580601600'))\nBuilderConfig","text":""},{"location":"plugins/utilities/#hatchling.builders.config.BuilderConfig.directory","title":"directory: strproperty","text":""},{"location":"plugins/utilities/#hatchling.builders.config.BuilderConfig.ignore_vcs","title":"ignore_vcs: boolproperty","text":""},{"location":"plugins/utilities/#hatchling.builders.config.BuilderConfig.reproducible","title":"reproducible: boolproperty","text":"Whether or not the target should be built in a reproducible manner, defaulting to true.
"},{"location":"plugins/utilities/#hatchling.builders.config.BuilderConfig.dev_mode_dirs","title":"dev_mode_dirs: list[str]property","text":"Directories which must be added to Python's search path in dev mode.
"},{"location":"plugins/utilities/#hatchling.builders.config.BuilderConfig.versions","title":"versions: list[str]property","text":""},{"location":"plugins/utilities/#hatchling.builders.config.BuilderConfig.dependencies","title":"dependencies: list[str]property","text":""},{"location":"plugins/utilities/#hatchling.builders.config.BuilderConfig.default_include","title":"default_include() -> list","text":""},{"location":"plugins/utilities/#hatchling.builders.config.BuilderConfig.default_exclude","title":"default_exclude() -> list","text":""},{"location":"plugins/utilities/#hatchling.builders.config.BuilderConfig.default_packages","title":"default_packages() -> list","text":""},{"location":"plugins/utilities/#hatchling.builders.config.BuilderConfig.default_only_include","title":"default_only_include() -> list","text":""},{"location":"plugins/utilities/#hatchling.bridge.app.Application","title":"Application","text":"The way output is displayed can be configured by users.
Important
Never import this directly; Hatch judiciously decides if a type of plugin requires the capabilities herein and will grant access via an attribute.
"},{"location":"plugins/utilities/#hatchling.bridge.app.Application.verbosity","title":"verbosity: intproperty","text":"The verbosity level of the application, with 0 as the default.
"},{"location":"plugins/utilities/#hatchling.bridge.app.Application.abort","title":"abort(message: str = '', code: int = 1, **kwargs: Any) -> None","text":"Terminate the program with the given return code.
"},{"location":"plugins/utilities/#hatchling.bridge.app.Application.display_debug","title":"display_debug(message: str = '', level: int = 1, **kwargs: Any) -> None","text":"Meant to be used for messages that are not useful for most user experiences. The
"},{"location":"plugins/utilities/#hatchling.bridge.app.Application.display_error","title":"leveloption must be between 1 and 3 (inclusive).display_error(message: str = '', **kwargs: Any) -> None","text":"Meant to be used for messages indicating some unrecoverable error.
"},{"location":"plugins/utilities/#hatchling.bridge.app.Application.display_info","title":"display_info(message: str = '', **kwargs: Any) -> None","text":"Meant to be used for messages conveying basic information.
"},{"location":"plugins/utilities/#hatchling.bridge.app.Application.display_success","title":"display_success(message: str = '', **kwargs: Any) -> None","text":"Meant to be used for messages indicating some positive outcome.
"},{"location":"plugins/utilities/#hatchling.bridge.app.Application.display_waiting","title":"display_waiting(message: str = '', **kwargs: Any) -> None","text":"Meant to be used for messages shown before potentially time consuming operations.
"},{"location":"plugins/utilities/#hatchling.bridge.app.Application.display_warning","title":"display_warning(message: str = '', **kwargs: Any) -> None","text":"Meant to be used for messages conveying important information.
"},{"location":"plugins/utilities/#hatch.utils.platform.Platform","title":"Platform","text":""},{"location":"plugins/utilities/#hatch.utils.platform.Platform.default_shell","title":"default_shell: strproperty","text":"Returns the default shell of the system.
On Windows systems first try the
"},{"location":"plugins/utilities/#hatch.utils.platform.Platform.modules","title":"SHELLenvironment variable, if present, followed by theCOMSPECenvironment variable, defaulting tocmd. On all other platforms only theSHELLenvironment variable will be used, defaulting tobash.modules: LazilyLoadedModulesproperty","text":"Accessor for lazily loading modules that either take multiple milliseconds to import (like
"},{"location":"plugins/utilities/#hatch.utils.platform.Platform.home","title":"shutilandsubprocess) or are not used on all platforms (likeshlex).home: Pathproperty","text":"The user's home directory as a path-like object.
"},{"location":"plugins/utilities/#hatch.utils.platform.Platform.name","title":"name: strproperty","text":"One of the following:
linuxwindowsmacos
display_name: strproperty","text":"One of the following:
LinuxWindowsmacOS
windows: boolproperty","text":"Indicates whether Hatch is running on Windows.
"},{"location":"plugins/utilities/#hatch.utils.platform.Platform.macos","title":"macos: boolproperty","text":"Indicates whether Hatch is running on macOS.
"},{"location":"plugins/utilities/#hatch.utils.platform.Platform.linux","title":"linux: boolproperty","text":"Indicates whether Hatch is running on neither Windows nor macOS.
"},{"location":"plugins/utilities/#hatch.utils.platform.Platform.format_for_subprocess","title":"format_for_subprocess(command: str | list[str], *, shell: bool) -> str | list[str]","text":"Format the given command in a cross-platform manner for immediate consumption by subprocess utilities.
"},{"location":"plugins/utilities/#hatch.utils.platform.Platform.run_command","title":"run_command(command: str | list[str], *, shell: bool = False, **kwargs: Any) -> CompletedProcess","text":"Equivalent to the standard library's subprocess.run, with the command first being properly formatted.
"},{"location":"plugins/utilities/#hatch.utils.platform.Platform.check_command","title":"check_command(command: str | list[str], *, shell: bool = False, **kwargs: Any) -> CompletedProcess","text":"Equivalent to run_command, but non-zero exit codes will gracefully end program execution.
"},{"location":"plugins/utilities/#hatch.utils.platform.Platform.check_command_output","title":"check_command_output(command: str | list[str], *, shell: bool = False, **kwargs: Any) -> str","text":"Equivalent to the output from the process returned by capture_process, but non-zero exit codes will gracefully end program execution.
"},{"location":"plugins/utilities/#hatch.utils.platform.Platform.capture_process","title":"capture_process(command: str | list[str], *, shell: bool = False, **kwargs: Any) -> Popen","text":"Equivalent to the standard library's subprocess.Popen, with all output captured by
"},{"location":"plugins/utilities/#hatch.utils.platform.Platform.exit_with_command","title":"stdoutand the command first being properly formatted.exit_with_command(command: list[str]) -> None","text":"Run the given command and exit with its exit code. On non-Windows systems, this uses the standard library's os.execvp.
"},{"location":"plugins/utilities/#hatch.env.context.EnvironmentContextFormatter","title":"EnvironmentContextFormatter","text":""},{"location":"plugins/utilities/#hatch.env.context.EnvironmentContextFormatter.formatters","title":"formatters()","text":"This returns a mapping of supported field names to their respective formatting functions. Each function accepts 2 arguments:
- the
valuethat was passed to the format call, defaulting toNone - the modifier
data, defaulting to an empty string
This is a custom class in a given Python file that inherits from the BuildHookInterface.
"},{"location":"plugins/build-hook/custom/#configuration","title":"Configuration","text":"The build hook plugin name is
pyproject.toml hatch.tomlcustom.[tool.hatch.build.hooks.custom]\n[tool.hatch.build.targets.<TARGET_NAME>.hooks.custom]\n
"},{"location":"plugins/build-hook/custom/#options","title":"Options","text":"Option Default Description[build.hooks.custom]\n[build.targets.<TARGET_NAME>.hooks.custom]\npathhatch_build.pyThe path of the Python file"},{"location":"plugins/build-hook/custom/#example","title":"Example","text":"hatch_build.pyfrom hatchling.builders.hooks.plugin.interface import BuildHookInterface\n\n\nclass CustomBuildHook(BuildHookInterface):\n ...\nIf multiple subclasses are found, you must define a function named
get_build_hookthat returns the desired build hook.Note
Any defined PLUGIN_NAME is ignored and will always be
"},{"location":"plugins/build-hook/reference/","title":"Build hook plugins","text":"custom.A build hook provides code that will be executed at various stages of the build process. See the documentation for build hook configuration.
"},{"location":"plugins/build-hook/reference/#known-third-party","title":"Known third-party","text":"- hatch-argparse-manpage - generate man pages for argparse-based CLIs
- hatch-autorun - used to inject code into an installation that will automatically run before the first import
- hatch-build-scripts - run arbitrary shell commands that create artifacts
- hatch-cython - build Cython extensions
- hatch-gettext - compiles multi-lingual messages with GNU
gettexttools - hatch-jupyter-builder - used for packages in the Project Jupyter ecosystem
- hatch-mypyc - compiles code with Mypyc
- hatch-odoo - package Odoo add-ons into the appropriate namespace
- scikit-build-core - build extension modules with CMake
Build hooks run for every selected version of build targets.
The initialization stage occurs immediately before each build and the finalization stage occurs immediately after. Each stage has the opportunity to view or modify build data.
"},{"location":"plugins/build-hook/reference/#build-data","title":"Build data","text":"Build data is a simple mapping whose contents can influence the behavior of builds. Which fields exist and are recognized depends on each build target.
The following fields are always present and recognized by the build system itself:
Field Type Descriptionartifactslist[str]This is a list of extraartifactpatterns and should generally only be appended toforce_includedict[str, str]This is a mapping of extra forced inclusion paths, with this mapping taking precedence in case of conflictsbuild_hookstuple[str, ...]This is an immutable sequence of the names of the configured build hooks and matches the order in which they runAttention
While user-facing TOML options are hyphenated, build data fields should be named with underscores to allow plugins to use them as valid Python identifiers.
"},{"location":"plugins/build-hook/reference/#notes","title":"Notes","text":"In some cases it may be necessary to use
force_includerather thanartifacts. For example, say that you want to install alib.sodirectly at the root ofsite-packagesand a project defines a packagesrc/foo. If you createsrc/lib.so, there will never be a match because the directory traversal starts atsrc/foorather thansrc. In that case you must do either:build_data['force_include']['src/lib.so'] = 'src/lib.so'\nor
"},{"location":"plugins/build-hook/reference/#hatchling.builders.hooks.plugin.interface.BuildHookInterface","title":"build_data['force_include']['/absolute/path/to/src/lib.so'] = 'src/lib.so'\nBuildHookInterface","text":"Example usage:
plugin.py hooks.pyfrom hatchling.builders.hooks.plugin.interface import BuildHookInterface\n\n\nclass SpecialBuildHook(BuildHookInterface):\n PLUGIN_NAME = 'special'\n ...\n
Source code infrom hatchling.plugin import hookimpl\n\nfrom .plugin import SpecialBuildHook\n\n\n@hookimpl\ndef hatch_register_build_hook():\n return SpecialBuildHook\nbackend/src/hatchling/builders/hooks/plugin/interface.py
"},{"location":"plugins/build-hook/reference/#hatchling.builders.hooks.plugin.interface.BuildHookInterface.PLUGIN_NAME","title":"class BuildHookInterface(Generic[BuilderConfigBound]): # no cov\n \"\"\"\n Example usage:\n\n ```python tab=\"plugin.py\"\n from hatchling.builders.hooks.plugin.interface import BuildHookInterface\n\n\n class SpecialBuildHook(BuildHookInterface):\n PLUGIN_NAME = 'special'\n ...\n ```\n\n ```python tab=\"hooks.py\"\n from hatchling.plugin import hookimpl\n\n from .plugin import SpecialBuildHook\n\n\n @hookimpl\n def hatch_register_build_hook():\n return SpecialBuildHook\n ```\n \"\"\"\n\n PLUGIN_NAME = ''\n \"\"\"The name used for selection.\"\"\"\n\n def __init__(\n self,\n root: str,\n config: dict[str, Any],\n build_config: BuilderConfigBound,\n metadata: ProjectMetadata,\n directory: str,\n target_name: str,\n app: Application | None = None,\n ) -> None:\n self.__root = root\n self.__config = config\n self.__build_config = build_config\n self.__metadata = metadata\n self.__directory = directory\n self.__target_name = target_name\n self.__app = app\n\n @property\n def app(self) -> Application:\n \"\"\"\n An instance of [Application](../utilities.md#hatchling.bridge.app.Application).\n \"\"\"\n if self.__app is None:\n from hatchling.bridge.app import Application\n\n self.__app = cast(Application, Application().get_safe_application())\n\n return self.__app\n\n @property\n def root(self) -> str:\n \"\"\"\n The root of the project tree.\n \"\"\"\n return self.__root\n\n @property\n def config(self) -> dict[str, Any]:\n \"\"\"\n The cumulative hook configuration.\n\n ```toml config-example\n [tool.hatch.build.hooks.<PLUGIN_NAME>]\n [tool.hatch.build.targets.<TARGET_NAME>.hooks.<PLUGIN_NAME>]\n ```\n \"\"\"\n return self.__config\n\n @property\n def metadata(self) -> ProjectMetadata:\n # Undocumented for now\n return self.__metadata\n\n @property\n def build_config(self) -> BuilderConfigBound:\n \"\"\"\n An instance of [BuilderConfig](../utilities.md#hatchling.builders.config.BuilderConfig).\n \"\"\"\n return self.__build_config\n\n @property\n def directory(self) -> str:\n \"\"\"\n The build directory.\n \"\"\"\n return self.__directory\n\n @property\n def target_name(self) -> str:\n \"\"\"\n The plugin name of the build target.\n \"\"\"\n return self.__target_name\n\n def dependencies(self) -> list[str]: # noqa: PLR6301\n \"\"\"\n A list of extra [dependencies](../../config/dependency.md) that must be installed\n prior to builds.\n\n !!! warning\n - For this to have any effect the hook dependency itself cannot be dynamic and\n must always be defined in `build-system.requires`.\n - As the hook must be imported to call this method, imports that require these\n dependencies must be evaluated lazily.\n \"\"\"\n return []\n\n def clean(self, versions: list[str]) -> None:\n \"\"\"\n This occurs before the build process if the `-c`/`--clean` flag was passed to\n the [`build`](../../cli/reference.md#hatch-build) command, or when invoking\n the [`clean`](../../cli/reference.md#hatch-clean) command.\n \"\"\"\n\n def initialize(self, version: str, build_data: dict[str, Any]) -> None:\n \"\"\"\n This occurs immediately before each build.\n\n Any modifications to the build data will be seen by the build target.\n \"\"\"\n\n def finalize(self, version: str, build_data: dict[str, Any], artifact_path: str) -> None:\n \"\"\"\n This occurs immediately after each build and will not run if the `--hooks-only` flag\n was passed to the [`build`](../../cli/reference.md#hatch-build) command.\n\n The build data will reflect any modifications done by the target during the build.\n \"\"\"\nPLUGIN_NAME = ''class-attributeinstance-attribute","text":"The name used for selection.
"},{"location":"plugins/build-hook/reference/#hatchling.builders.hooks.plugin.interface.BuildHookInterface.app","title":"app: Applicationproperty","text":"An instance of Application.
"},{"location":"plugins/build-hook/reference/#hatchling.builders.hooks.plugin.interface.BuildHookInterface.root","title":"root: strproperty","text":"The root of the project tree.
"},{"location":"plugins/build-hook/reference/#hatchling.builders.hooks.plugin.interface.BuildHookInterface.config","title":"config: dict[str, Any]property","text":"The cumulative hook configuration.
pyproject.toml hatch.toml[tool.hatch.build.hooks.<PLUGIN_NAME>]\n[tool.hatch.build.targets.<TARGET_NAME>.hooks.<PLUGIN_NAME>]\n
"},{"location":"plugins/build-hook/reference/#hatchling.builders.hooks.plugin.interface.BuildHookInterface.build_config","title":"[build.hooks.<PLUGIN_NAME>]\n[build.targets.<TARGET_NAME>.hooks.<PLUGIN_NAME>]\nbuild_config: BuilderConfigBoundproperty","text":"An instance of BuilderConfig.
"},{"location":"plugins/build-hook/reference/#hatchling.builders.hooks.plugin.interface.BuildHookInterface.target_name","title":"target_name: strproperty","text":"The plugin name of the build target.
"},{"location":"plugins/build-hook/reference/#hatchling.builders.hooks.plugin.interface.BuildHookInterface.directory","title":"directory: strproperty","text":"The build directory.
"},{"location":"plugins/build-hook/reference/#hatchling.builders.hooks.plugin.interface.BuildHookInterface.dependencies","title":"dependencies() -> list[str]","text":"A list of extra dependencies that must be installed prior to builds.
Warning
- For this to have any effect the hook dependency itself cannot be dynamic and must always be defined in
build-system.requires. - As the hook must be imported to call this method, imports that require these dependencies must be evaluated lazily.
backend/src/hatchling/builders/hooks/plugin/interface.py
"},{"location":"plugins/build-hook/reference/#hatchling.builders.hooks.plugin.interface.BuildHookInterface.clean","title":"def dependencies(self) -> list[str]: # noqa: PLR6301\n \"\"\"\n A list of extra [dependencies](../../config/dependency.md) that must be installed\n prior to builds.\n\n !!! warning\n - For this to have any effect the hook dependency itself cannot be dynamic and\n must always be defined in `build-system.requires`.\n - As the hook must be imported to call this method, imports that require these\n dependencies must be evaluated lazily.\n \"\"\"\n return []\nclean(versions: list[str]) -> None","text":"This occurs before the build process if the
Source code in-c/--cleanflag was passed to thebuildcommand, or when invoking thecleancommand.backend/src/hatchling/builders/hooks/plugin/interface.py
"},{"location":"plugins/build-hook/reference/#hatchling.builders.hooks.plugin.interface.BuildHookInterface.initialize","title":"def clean(self, versions: list[str]) -> None:\n \"\"\"\n This occurs before the build process if the `-c`/`--clean` flag was passed to\n the [`build`](../../cli/reference.md#hatch-build) command, or when invoking\n the [`clean`](../../cli/reference.md#hatch-clean) command.\n \"\"\"\ninitialize(version: str, build_data: dict[str, Any]) -> None","text":"This occurs immediately before each build.
Any modifications to the build data will be seen by the build target.
Source code inbackend/src/hatchling/builders/hooks/plugin/interface.py
"},{"location":"plugins/build-hook/reference/#hatchling.builders.hooks.plugin.interface.BuildHookInterface.finalize","title":"def initialize(self, version: str, build_data: dict[str, Any]) -> None:\n \"\"\"\n This occurs immediately before each build.\n\n Any modifications to the build data will be seen by the build target.\n \"\"\"\nfinalize(version: str, build_data: dict[str, Any], artifact_path: str) -> None","text":"This occurs immediately after each build and will not run if the
--hooks-onlyflag was passed to thebuildcommand.The build data will reflect any modifications done by the target during the build.
Source code inbackend/src/hatchling/builders/hooks/plugin/interface.py
"},{"location":"plugins/build-hook/version/","title":"Version build hook","text":"def finalize(self, version: str, build_data: dict[str, Any], artifact_path: str) -> None:\n \"\"\"\n This occurs immediately after each build and will not run if the `--hooks-only` flag\n was passed to the [`build`](../../cli/reference.md#hatch-build) command.\n\n The build data will reflect any modifications done by the target during the build.\n \"\"\"\nThis writes the project's version to a file.
"},{"location":"plugins/build-hook/version/#configuration","title":"Configuration","text":"The build hook plugin name is
pyproject.toml hatch.tomlversion.[tool.hatch.build.hooks.version]\n[tool.hatch.build.targets.<TARGET_NAME>.hooks.version]\n
"},{"location":"plugins/build-hook/version/#options","title":"Options","text":"Option Description[build.hooks.version]\n[build.targets.<TARGET_NAME>.hooks.version]\npath(required) A relative path to the desired filetemplateA string representing the entire contents ofpaththat will be formatted with aversionvariablepatternRather than updating the entire file, a regular expression may be used that has a named group calledversionthat represents the version. If set totrue, a pattern will be used that looks for a variable named__version__orVERSIONthat is set to a string containing the version, optionally prefixed with the lowercase letterv."},{"location":"plugins/builder/binary/","title":"Binary builder","text":"This uses PyApp to build an application that is able to bootstrap itself at runtime.
Note
This requires an installation of Rust.
"},{"location":"plugins/builder/binary/#configuration","title":"Configuration","text":"The builder plugin name is
pyproject.toml hatch.tomlbinary.[tool.hatch.build.targets.binary]\n
"},{"location":"plugins/builder/binary/#options","title":"Options","text":"Option Default Description[build.targets.binary]\nscriptsall defined An array of defined script names to limit what gets builtpython-versionlatest compatible Python minor version The Python version ID to usepyapp-versionThe version of PyApp to use"},{"location":"plugins/builder/binary/#build-behavior","title":"Build behavior","text":"If any scripts are defined then each one will be built (limited by the
scriptsoption). Otherwise, a single executable will be built based on the project name assuming there is an equivalently named module with a__main__.pyfile.Every executable will be built inside an
appdirectory in the output directory.If the
CARGOenvironment variable is set then that path will be used as the executable for performing builds.If the
CARGO_BUILD_TARGETenvironment variable is set then its value will be appended to the file name stems.If the
"},{"location":"plugins/builder/custom/","title":"Custom builder","text":"PYAPP_REPOenvironment variable is set then a local build will be performed inside that directory rather than installing from crates.io. Note that this is required if theCARGOenvironment variable refers to cross.This is a custom class in a given Python file that inherits from the BuilderInterface.
"},{"location":"plugins/builder/custom/#configuration","title":"Configuration","text":"The builder plugin name is
pyproject.toml hatch.tomlcustom.[tool.hatch.build.targets.custom]\n
"},{"location":"plugins/builder/custom/#options","title":"Options","text":"Option Default Description[build.targets.custom]\npathhatch_build.pyThe path of the Python file"},{"location":"plugins/builder/custom/#example","title":"Example","text":"hatch_build.pyfrom hatchling.builders.plugin.interface import BuilderInterface\n\n\nclass CustomBuilder(BuilderInterface):\n ...\nIf multiple subclasses are found, you must define a function named
get_builderthat returns the desired builder.Note
Any defined PLUGIN_NAME is ignored and will always be
"},{"location":"plugins/builder/reference/","title":"Builder plugins","text":"custom.See the documentation for build configuration.
"},{"location":"plugins/builder/reference/#known-third-party","title":"Known third-party","text":"- hatch-aws - used for building AWS Lambda functions with SAM
- hatch-zipped-directory - used for building ZIP archives for installation into various foreign package installation systems
BuilderInterface","text":"Example usage:
plugin.py hooks.pyfrom hatchling.builders.plugin.interface import BuilderInterface\n\n\nclass SpecialBuilder(BuilderInterface):\n PLUGIN_NAME = 'special'\n ...\n
Source code infrom hatchling.plugin import hookimpl\n\nfrom .plugin import SpecialBuilder\n\n\n@hookimpl\ndef hatch_register_builder():\n return SpecialBuilder\nbackend/src/hatchling/builders/plugin/interface.py
"},{"location":"plugins/builder/reference/#hatchling.builders.plugin.interface.BuilderInterface.PLUGIN_NAME","title":"class BuilderInterface(ABC, Generic[BuilderConfigBound, PluginManagerBound]):\n \"\"\"\n Example usage:\n\n ```python tab=\"plugin.py\"\n from hatchling.builders.plugin.interface import BuilderInterface\n\n\n class SpecialBuilder(BuilderInterface):\n PLUGIN_NAME = 'special'\n ...\n ```\n\n ```python tab=\"hooks.py\"\n from hatchling.plugin import hookimpl\n\n from .plugin import SpecialBuilder\n\n\n @hookimpl\n def hatch_register_builder():\n return SpecialBuilder\n ```\n \"\"\"\n\n PLUGIN_NAME = ''\n \"\"\"The name used for selection.\"\"\"\n\n def __init__(\n self,\n root: str,\n plugin_manager: PluginManagerBound | None = None,\n config: dict[str, Any] | None = None,\n metadata: ProjectMetadata | None = None,\n app: Application | None = None,\n ) -> None:\n self.__root = root\n self.__plugin_manager = cast(PluginManagerBound, plugin_manager)\n self.__raw_config = config\n self.__metadata = metadata\n self.__app = app\n self.__config = cast(BuilderConfigBound, None)\n self.__project_config: dict[str, Any] | None = None\n self.__hatch_config: dict[str, Any] | None = None\n self.__build_config: dict[str, Any] | None = None\n self.__build_targets: list[str] | None = None\n self.__target_config: dict[str, Any] | None = None\n\n # Metadata\n self.__project_id: str | None = None\n\n def build(\n self,\n *,\n directory: str | None = None,\n versions: list[str] | None = None,\n hooks_only: bool | None = None,\n clean: bool | None = None,\n clean_hooks_after: bool | None = None,\n clean_only: bool | None = False,\n ) -> Generator[str, None, None]:\n # Fail early for invalid project metadata\n self.metadata.validate_fields()\n\n if directory is None:\n directory = (\n self.config.normalize_build_directory(os.environ[BuildEnvVars.LOCATION])\n if BuildEnvVars.LOCATION in os.environ\n else self.config.directory\n )\n\n if not os.path.isdir(directory):\n os.makedirs(directory)\n\n version_api = self.get_version_api()\n\n versions = versions or self.config.versions\n if versions:\n unknown_versions = set(versions) - set(version_api)\n if unknown_versions:\n message = (\n f'Unknown versions for target `{self.PLUGIN_NAME}`: {\", \".join(map(str, sorted(unknown_versions)))}'\n )\n raise ValueError(message)\n\n if hooks_only is None:\n hooks_only = env_var_enabled(BuildEnvVars.HOOKS_ONLY)\n\n configured_build_hooks = self.get_build_hooks(directory)\n build_hooks = list(configured_build_hooks.values())\n\n if clean_only:\n clean = True\n elif clean is None:\n clean = env_var_enabled(BuildEnvVars.CLEAN)\n if clean:\n if not hooks_only:\n self.clean(directory, versions)\n\n for build_hook in build_hooks:\n build_hook.clean(versions)\n\n if clean_only:\n return\n\n if clean_hooks_after is None:\n clean_hooks_after = env_var_enabled(BuildEnvVars.CLEAN_HOOKS_AFTER)\n\n for version in versions:\n self.app.display_debug(f'Building `{self.PLUGIN_NAME}` version `{version}`')\n\n build_data = self.get_default_build_data()\n self.set_build_data_defaults(build_data)\n\n # Allow inspection of configured build hooks and the order in which they run\n build_data['build_hooks'] = tuple(configured_build_hooks)\n\n # Execute all `initialize` build hooks\n for build_hook in build_hooks:\n build_hook.initialize(version, build_data)\n\n if hooks_only:\n self.app.display_debug(f'Only ran build hooks for `{self.PLUGIN_NAME}` version `{version}`')\n continue\n\n # Build the artifact\n with self.config.set_build_data(build_data):\n artifact = version_api[version](directory, **build_data)\n\n # Execute all `finalize` build hooks\n for build_hook in build_hooks:\n build_hook.finalize(version, build_data, artifact)\n\n if clean_hooks_after:\n for build_hook in build_hooks:\n build_hook.clean([version])\n\n yield artifact\n\n def recurse_included_files(self) -> Iterable[IncludedFile]:\n \"\"\"\n Returns a consistently generated series of file objects for every file that should be distributed. Each file\n object has three `str` attributes:\n\n - `path` - the absolute path\n - `relative_path` - the path relative to the project root; will be an empty string for external files\n - `distribution_path` - the path to be distributed as\n \"\"\"\n yield from self.recurse_selected_project_files()\n yield from self.recurse_forced_files(self.config.get_force_include())\n\n def recurse_selected_project_files(self) -> Iterable[IncludedFile]:\n if self.config.only_include:\n yield from self.recurse_explicit_files(self.config.only_include)\n else:\n yield from self.recurse_project_files()\n\n def recurse_project_files(self) -> Iterable[IncludedFile]:\n for root, dirs, files in safe_walk(self.root):\n relative_path = get_relative_path(root, self.root)\n\n dirs[:] = sorted(d for d in dirs if not self.config.directory_is_excluded(d, relative_path))\n\n files.sort()\n is_package = '__init__.py' in files\n for f in files:\n if f in EXCLUDED_FILES:\n continue\n\n relative_file_path = os.path.join(relative_path, f)\n distribution_path = self.config.get_distribution_path(relative_file_path)\n if self.config.path_is_reserved(distribution_path):\n continue\n\n if self.config.include_path(relative_file_path, is_package=is_package):\n yield IncludedFile(\n os.path.join(root, f), relative_file_path, self.config.get_distribution_path(relative_file_path)\n )\n\n def recurse_forced_files(self, inclusion_map: dict[str, str]) -> Iterable[IncludedFile]:\n for source, target_path in inclusion_map.items():\n external = not source.startswith(self.root)\n if os.path.isfile(source):\n yield IncludedFile(\n source,\n '' if external else os.path.relpath(source, self.root),\n self.config.get_distribution_path(target_path),\n )\n elif os.path.isdir(source):\n for root, dirs, files in safe_walk(source):\n relative_directory = get_relative_path(root, source)\n\n dirs[:] = sorted(d for d in dirs if d not in EXCLUDED_DIRECTORIES)\n\n files.sort()\n for f in files:\n if f in EXCLUDED_FILES:\n continue\n\n relative_file_path = os.path.join(target_path, relative_directory, f)\n distribution_path = self.config.get_distribution_path(relative_file_path)\n if not self.config.path_is_reserved(distribution_path):\n yield IncludedFile(\n os.path.join(root, f),\n '' if external else relative_file_path,\n distribution_path,\n )\n else:\n msg = f'Forced include not found: {source}'\n raise FileNotFoundError(msg)\n\n def recurse_explicit_files(self, inclusion_map: dict[str, str]) -> Iterable[IncludedFile]:\n for source, target_path in inclusion_map.items():\n external = not source.startswith(self.root)\n if os.path.isfile(source):\n distribution_path = self.config.get_distribution_path(target_path)\n if not self.config.path_is_reserved(distribution_path):\n yield IncludedFile(\n source,\n '' if external else os.path.relpath(source, self.root),\n self.config.get_distribution_path(target_path),\n )\n elif os.path.isdir(source):\n for root, dirs, files in safe_walk(source):\n relative_directory = get_relative_path(root, source)\n\n dirs[:] = sorted(d for d in dirs if d not in EXCLUDED_DIRECTORIES)\n\n files.sort()\n is_package = '__init__.py' in files\n for f in files:\n if f in EXCLUDED_FILES:\n continue\n\n relative_file_path = os.path.join(target_path, relative_directory, f)\n distribution_path = self.config.get_distribution_path(relative_file_path)\n if self.config.path_is_reserved(distribution_path):\n continue\n\n if self.config.include_path(relative_file_path, explicit=True, is_package=is_package):\n yield IncludedFile(\n os.path.join(root, f), '' if external else relative_file_path, distribution_path\n )\n\n @property\n def root(self) -> str:\n \"\"\"\n The root of the project tree.\n \"\"\"\n return self.__root\n\n @property\n def plugin_manager(self) -> PluginManagerBound:\n if self.__plugin_manager is None:\n from hatchling.plugin.manager import PluginManager\n\n self.__plugin_manager = PluginManager()\n\n return self.__plugin_manager\n\n @property\n def metadata(self) -> ProjectMetadata:\n if self.__metadata is None:\n from hatchling.metadata.core import ProjectMetadata\n\n self.__metadata = ProjectMetadata(self.root, self.plugin_manager, self.__raw_config)\n\n return self.__metadata\n\n @property\n def app(self) -> Application:\n \"\"\"\n An instance of [Application](../utilities.md#hatchling.bridge.app.Application).\n \"\"\"\n if self.__app is None:\n from hatchling.bridge.app import Application\n\n self.__app = cast(Application, Application().get_safe_application())\n\n return self.__app\n\n @property\n def raw_config(self) -> dict[str, Any]:\n if self.__raw_config is None:\n self.__raw_config = self.metadata.config\n\n return self.__raw_config\n\n @property\n def project_config(self) -> dict[str, Any]:\n if self.__project_config is None:\n self.__project_config = self.metadata.core.config\n\n return self.__project_config\n\n @property\n def hatch_config(self) -> dict[str, Any]:\n if self.__hatch_config is None:\n self.__hatch_config = self.metadata.hatch.config\n\n return self.__hatch_config\n\n @property\n def config(self) -> BuilderConfigBound:\n \"\"\"\n An instance of [BuilderConfig](../utilities.md#hatchling.builders.config.BuilderConfig).\n \"\"\"\n if self.__config is None:\n self.__config = self.get_config_class()(\n self, self.root, self.PLUGIN_NAME, self.build_config, self.target_config\n )\n\n return self.__config\n\n @property\n def build_config(self) -> dict[str, Any]:\n \"\"\"\n ```toml config-example\n [tool.hatch.build]\n ```\n \"\"\"\n if self.__build_config is None:\n self.__build_config = self.metadata.hatch.build_config\n\n return self.__build_config\n\n @property\n def target_config(self) -> dict[str, Any]:\n \"\"\"\n ```toml config-example\n [tool.hatch.build.targets.<PLUGIN_NAME>]\n ```\n \"\"\"\n if self.__target_config is None:\n target_config: dict[str, Any] = self.metadata.hatch.build_targets.get(self.PLUGIN_NAME, {})\n if not isinstance(target_config, dict):\n message = f'Field `tool.hatch.build.targets.{self.PLUGIN_NAME}` must be a table'\n raise TypeError(message)\n\n self.__target_config = target_config\n\n return self.__target_config\n\n @property\n def project_id(self) -> str:\n if self.__project_id is None:\n self.__project_id = f'{self.normalize_file_name_component(self.metadata.core.name)}-{self.metadata.version}'\n\n return self.__project_id\n\n def get_build_hooks(self, directory: str) -> dict[str, BuildHookInterface]:\n configured_build_hooks = {}\n for hook_name, config in self.config.hook_config.items():\n build_hook = self.plugin_manager.build_hook.get(hook_name)\n if build_hook is None:\n from hatchling.plugin.exceptions import UnknownPluginError\n\n message = f'Unknown build hook: {hook_name}'\n raise UnknownPluginError(message)\n\n configured_build_hooks[hook_name] = build_hook(\n self.root, config, self.config, self.metadata, directory, self.PLUGIN_NAME, self.app\n )\n\n return configured_build_hooks\n\n @abstractmethod\n def get_version_api(self) -> dict[str, Callable]:\n \"\"\"\n A mapping of `str` versions to a callable that is used for building.\n Each callable must have the following signature:\n\n ```python\n def ...(build_dir: str, build_data: dict) -> str:\n ```\n\n The return value must be the absolute path to the built artifact.\n \"\"\"\n\n def get_default_versions(self) -> list[str]:\n \"\"\"\n A list of versions to build when users do not specify any, defaulting to all versions.\n \"\"\"\n return list(self.get_version_api())\n\n def get_default_build_data(self) -> dict[str, Any]: # noqa: PLR6301\n \"\"\"\n A mapping that can be modified by [build hooks](../build-hook/reference.md) to influence the behavior of builds.\n \"\"\"\n return {}\n\n def set_build_data_defaults(self, build_data: dict[str, Any]) -> None: # noqa: PLR6301\n build_data.setdefault('artifacts', [])\n build_data.setdefault('force_include', {})\n\n def clean(self, directory: str, versions: list[str]) -> None:\n \"\"\"\n Called before builds if the `-c`/`--clean` flag was passed to the\n [`build`](../../cli/reference.md#hatch-build) command.\n \"\"\"\n\n @classmethod\n def get_config_class(cls) -> type[BuilderConfig]:\n \"\"\"\n Must return a subclass of [BuilderConfig](../utilities.md#hatchling.builders.config.BuilderConfig).\n \"\"\"\n return BuilderConfig\n\n @staticmethod\n def normalize_file_name_component(file_name: str) -> str:\n \"\"\"\n https://peps.python.org/pep-0427/#escaping-and-unicode\n \"\"\"\n return re.sub(r'[^\\w\\d.]+', '_', file_name, flags=re.UNICODE)\nPLUGIN_NAME = ''class-attributeinstance-attribute","text":"The name used for selection.
"},{"location":"plugins/builder/reference/#hatchling.builders.plugin.interface.BuilderInterface.app","title":"app: Applicationproperty","text":"An instance of Application.
"},{"location":"plugins/builder/reference/#hatchling.builders.plugin.interface.BuilderInterface.root","title":"root: strproperty","text":"The root of the project tree.
"},{"location":"plugins/builder/reference/#hatchling.builders.plugin.interface.BuilderInterface.build_config","title":"build_config: dict[str, Any]property","text":"pyproject.toml hatch.toml[tool.hatch.build]\n
"},{"location":"plugins/builder/reference/#hatchling.builders.plugin.interface.BuilderInterface.target_config","title":"[build]\ntarget_config: dict[str, Any]property","text":"pyproject.toml hatch.toml[tool.hatch.build.targets.<PLUGIN_NAME>]\n
"},{"location":"plugins/builder/reference/#hatchling.builders.plugin.interface.BuilderInterface.config","title":"[build.targets.<PLUGIN_NAME>]\nconfig: BuilderConfigBoundproperty","text":"An instance of BuilderConfig.
"},{"location":"plugins/builder/reference/#hatchling.builders.plugin.interface.BuilderInterface.get_config_class","title":"get_config_class() -> type[BuilderConfig]classmethod","text":"Must return a subclass of BuilderConfig.
Source code inbackend/src/hatchling/builders/plugin/interface.py
"},{"location":"plugins/builder/reference/#hatchling.builders.plugin.interface.BuilderInterface.get_version_api","title":"@classmethod\ndef get_config_class(cls) -> type[BuilderConfig]:\n \"\"\"\n Must return a subclass of [BuilderConfig](../utilities.md#hatchling.builders.config.BuilderConfig).\n \"\"\"\n return BuilderConfig\nget_version_api() -> dict[str, Callable]abstractmethod","text":"A mapping of
strversions to a callable that is used for building. Each callable must have the following signature:def ...(build_dir: str, build_data: dict) -> str:\nThe return value must be the absolute path to the built artifact.
Source code inbackend/src/hatchling/builders/plugin/interface.py
"},{"location":"plugins/builder/reference/#hatchling.builders.plugin.interface.BuilderInterface.get_default_versions","title":"@abstractmethod\ndef get_version_api(self) -> dict[str, Callable]:\n \"\"\"\n A mapping of `str` versions to a callable that is used for building.\n Each callable must have the following signature:\n\n ```python\n def ...(build_dir: str, build_data: dict) -> str:\n ```\n\n The return value must be the absolute path to the built artifact.\n \"\"\"\nget_default_versions() -> list[str]","text":"A list of versions to build when users do not specify any, defaulting to all versions.
Source code inbackend/src/hatchling/builders/plugin/interface.py
"},{"location":"plugins/builder/reference/#hatchling.builders.plugin.interface.BuilderInterface.clean","title":"def get_default_versions(self) -> list[str]:\n \"\"\"\n A list of versions to build when users do not specify any, defaulting to all versions.\n \"\"\"\n return list(self.get_version_api())\nclean(directory: str, versions: list[str]) -> None","text":"Called before builds if the
Source code in-c/--cleanflag was passed to thebuildcommand.backend/src/hatchling/builders/plugin/interface.py
"},{"location":"plugins/builder/reference/#hatchling.builders.plugin.interface.BuilderInterface.recurse_included_files","title":"def clean(self, directory: str, versions: list[str]) -> None:\n \"\"\"\n Called before builds if the `-c`/`--clean` flag was passed to the\n [`build`](../../cli/reference.md#hatch-build) command.\n \"\"\"\nrecurse_included_files() -> Iterable[IncludedFile]","text":"Returns a consistently generated series of file objects for every file that should be distributed. Each file object has three
strattributes:path- the absolute pathrelative_path- the path relative to the project root; will be an empty string for external filesdistribution_path- the path to be distributed as
backend/src/hatchling/builders/plugin/interface.py
"},{"location":"plugins/builder/reference/#hatchling.builders.plugin.interface.BuilderInterface.get_default_build_data","title":"def recurse_included_files(self) -> Iterable[IncludedFile]:\n \"\"\"\n Returns a consistently generated series of file objects for every file that should be distributed. Each file\n object has three `str` attributes:\n\n - `path` - the absolute path\n - `relative_path` - the path relative to the project root; will be an empty string for external files\n - `distribution_path` - the path to be distributed as\n \"\"\"\n yield from self.recurse_selected_project_files()\n yield from self.recurse_forced_files(self.config.get_force_include())\nget_default_build_data() -> dict[str, Any]","text":"A mapping that can be modified by build hooks to influence the behavior of builds.
Source code inbackend/src/hatchling/builders/plugin/interface.py
"},{"location":"plugins/builder/sdist/","title":"Source distribution builder","text":"def get_default_build_data(self) -> dict[str, Any]: # noqa: PLR6301\n \"\"\"\n A mapping that can be modified by [build hooks](../build-hook/reference.md) to influence the behavior of builds.\n \"\"\"\n return {}\nA source distribution, or
"},{"location":"plugins/builder/sdist/#configuration","title":"Configuration","text":"sdist, is an archive of Python \"source code\". Although largely unspecified, by convention it should include everything that is required to build a wheel without making network requests.The builder plugin name is
pyproject.toml hatch.tomlsdist.[tool.hatch.build.targets.sdist]\n
"},{"location":"plugins/builder/sdist/#options","title":"Options","text":"Option Default Description[build.targets.sdist]\ncore-metadata-version\"2.3\"The version of core metadata to usestrict-namingtrueWhether or not file names should contain the normalized version of the project namesupport-legacyfalseWhether or not to include asetup.pyfile to support legacy installation mechanisms"},{"location":"plugins/builder/sdist/#versions","title":"Versions","text":"Version Descriptionstandard(default) The latest conventional format"},{"location":"plugins/builder/sdist/#default-file-selection","title":"Default file selection","text":"When the user has not set any file selection options, all files that are not ignored by your VCS will be included.
Note
The following files are always included and cannot be excluded:
/pyproject.toml/hatch.toml/hatch_build.py/.gitignoreor/.hgignore- Any defined
readmefile - All defined
license-files
Reproducible builds are supported.
"},{"location":"plugins/builder/sdist/#build-data","title":"Build data","text":"This is data that can be modified by build hooks.
Data Default DescriptiondependenciesExtra project dependencies"},{"location":"plugins/builder/wheel/","title":"Wheel builder","text":"A wheel is a binary distribution of a Python package that can be installed directly into an environment.
"},{"location":"plugins/builder/wheel/#configuration","title":"Configuration","text":"The builder plugin name is
pyproject.toml hatch.tomlwheel.[tool.hatch.build.targets.wheel]\n
"},{"location":"plugins/builder/wheel/#options","title":"Options","text":"Option Default Description[build.targets.wheel]\ncore-metadata-version\"2.3\"The version of core metadata to useshared-dataA mapping similar to the forced inclusion option corresponding to thedatasubdirectory within the standard data directory that will be installed globally in a given Python environment, usually undersys.prefixshared-scriptsA mapping similar to the forced inclusion option corresponding to thescriptssubdirectory within the standard data directory that will be installed in a given Python environment, usually underScriptson Windows orbinotherwise, and would normally be available on PATHextra-metadataA mapping similar to the forced inclusion option corresponding to extra metadata that will be shipped in a directory namedextra_metadatastrict-namingtrueWhether or not file names should contain the normalized version of the project namemacos-max-compatfalseWhether or not on macOS, when build hooks have set theinfer_tagbuild data, the wheel name should signal broad support rather than specific versions for newer SDK versions.Note: This option will eventually be removed.bypass-selectionfalseWhether or not to suppress the error when one has not defined any file selection options and all heuristics have failed to determine what to ship"},{"location":"plugins/builder/wheel/#versions","title":"Versions","text":"Version Descriptionstandard(default) The latest standardized formateditableA wheel that only ships.pthfiles or import hooks for real-time development"},{"location":"plugins/builder/wheel/#default-file-selection","title":"Default file selection","text":"When the user has not set any file selection options, the project name will be used to determine the package to ship in the following heuristic order:
<NAME>/__init__.pysrc/<NAME>/__init__.py<NAME>.py<NAMESPACE>/<NAME>/__init__.py
If none of these heuristics are satisfied, an error will be raised.
"},{"location":"plugins/builder/wheel/#reproducibility","title":"Reproducibility","text":"Reproducible builds are supported.
"},{"location":"plugins/builder/wheel/#build-data","title":"Build data","text":"This is data that can be modified by build hooks.
Data Default DescriptiontagThe full tag part of the filename (e.g.py3-none-any), defaulting to a cross-platform wheel with the supported major versions of Python based on project metadatainfer_tagFalseWhentagis not set, this may be enabled to use the one most specific to the platform, Python interpreter, and ABIpure_pythonTrueWhether or not to write metadata indicating that the package does not contain any platform-specific filesdependenciesExtra project dependenciesshared_dataAdditionalshared-dataentries, which take precedence in case of conflictsshared_scriptsAdditionalshared-scriptsentries, which take precedence in case of conflictsextra_metadataAdditionalextra-metadataentries, which take precedence in case of conflictsforce_include_editableSimilar to theforce_includeoption but specifically for theeditableversion and takes precedence"},{"location":"plugins/environment/reference/","title":"Environment plugins","text":"See the documentation for environment configuration.
"},{"location":"plugins/environment/reference/#known-third-party","title":"Known third-party","text":"- hatch-conda - environments backed by Conda/Mamba
- hatch-containers - environments run inside containers
- hatch-pip-compile - use pip-compile to manage project dependencies and lockfiles
- hatch-pip-deepfreeze - virtual environments with dependency locking by pip-deepfreeze
Any required environment types that are not built-in must be manually installed alongside Hatch or listed in the
pyproject.toml hatch.tomltool.hatch.env.requiresarray for automatic management:[tool.hatch.env]\nrequires = [\n \"...\",\n]\n
"},{"location":"plugins/environment/reference/#life-cycle","title":"Life cycle","text":"[env]\nrequires = [\n \"...\",\n]\nWhenever an environment is used, the following logic is performed:
Source code insrc/hatch/cli/application.py
"},{"location":"plugins/environment/reference/#build-environments","title":"Build environments","text":"def prepare_environment(self, environment: EnvironmentInterface):\n if not environment.exists():\n self.env_metadata.reset(environment)\n\n with environment.app_status_creation():\n environment.create()\n\n if not environment.skip_install:\n if environment.pre_install_commands:\n with environment.app_status_pre_installation():\n self.run_shell_commands(\n ExecutionContext(\n environment,\n shell_commands=environment.pre_install_commands,\n source='pre-install',\n show_code_on_error=True,\n )\n )\n\n with environment.app_status_project_installation():\n if environment.dev_mode:\n environment.install_project_dev_mode()\n else:\n environment.install_project()\n\n if environment.post_install_commands:\n with environment.app_status_post_installation():\n self.run_shell_commands(\n ExecutionContext(\n environment,\n shell_commands=environment.post_install_commands,\n source='post-install',\n show_code_on_error=True,\n )\n )\n\n with environment.app_status_dependency_state_check():\n new_dep_hash = environment.dependency_hash()\n\n current_dep_hash = self.env_metadata.dependency_hash(environment)\n if new_dep_hash != current_dep_hash:\n with environment.app_status_dependency_installation_check():\n dependencies_in_sync = environment.dependencies_in_sync()\n\n if not dependencies_in_sync:\n with environment.app_status_dependency_synchronization():\n environment.sync_dependencies()\n new_dep_hash = environment.dependency_hash()\n\n self.env_metadata.update_dependency_hash(environment, new_dep_hash)\nAll environment types should offer support for a special sub-environment in which projects can be built. This environment is used in the following scenarios:
- the
buildcommand - commands that read dependencies, like
dep hash, if any project dependencies are set dynamically
EnvironmentInterface","text":"Example usage:
plugin.py hooks.pyfrom hatch.env.plugin.interface import EnvironmentInterface\n\n\n class SpecialEnvironment(EnvironmentInterface):\n PLUGIN_NAME = 'special'\n ...\n
Source code infrom hatchling.plugin import hookimpl\n\n from .plugin import SpecialEnvironment\n\n\n @hookimpl\n def hatch_register_environment():\n return SpecialEnvironment\nsrc/hatch/env/plugin/interface.py
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.PLUGIN_NAME","title":"class EnvironmentInterface(ABC):\n \"\"\"\n Example usage:\n\n ```python tab=\"plugin.py\"\n from hatch.env.plugin.interface import EnvironmentInterface\n\n\n class SpecialEnvironment(EnvironmentInterface):\n PLUGIN_NAME = 'special'\n ...\n ```\n\n ```python tab=\"hooks.py\"\n from hatchling.plugin import hookimpl\n\n from .plugin import SpecialEnvironment\n\n\n @hookimpl\n def hatch_register_environment():\n return SpecialEnvironment\n ```\n \"\"\"\n\n PLUGIN_NAME = ''\n \"\"\"The name used for selection.\"\"\"\n\n def __init__(\n self,\n root,\n metadata,\n name,\n config,\n matrix_variables,\n data_directory,\n isolated_data_directory,\n platform,\n verbosity,\n app=None,\n ):\n self.__root = root\n self.__metadata = metadata\n self.__name = name\n self.__config = config\n self.__matrix_variables = matrix_variables\n self.__data_directory = data_directory\n self.__isolated_data_directory = isolated_data_directory\n self.__platform = platform\n self.__verbosity = verbosity\n self.__app = app\n self.__context = None\n\n self._system_python = None\n self._env_vars = None\n self._env_include = None\n self._env_exclude = None\n self._environment_dependencies_complex = None\n self._environment_dependencies = None\n self._dependencies_complex = None\n self._dependencies = None\n self._platforms = None\n self._skip_install = None\n self._dev_mode = None\n self._features = None\n self._description = None\n self._scripts = None\n self._pre_install_commands = None\n self._post_install_commands = None\n\n @property\n def matrix_variables(self):\n return self.__matrix_variables\n\n @property\n def app(self):\n \"\"\"\n An instance of [Application](../utilities.md#hatchling.bridge.app.Application).\n \"\"\"\n if self.__app is None:\n from hatchling.bridge.app import Application\n\n self.__app = Application().get_safe_application()\n\n return self.__app\n\n @property\n def context(self):\n if self.__context is None:\n self.__context = self.get_context()\n\n return self.__context\n\n @property\n def verbosity(self):\n return self.__verbosity\n\n @property\n def root(self):\n \"\"\"\n The root of the project tree as a path-like object.\n \"\"\"\n return self.__root\n\n @property\n def metadata(self):\n return self.__metadata\n\n @property\n def name(self) -> str:\n \"\"\"\n The name of the environment.\n \"\"\"\n return self.__name\n\n @property\n def platform(self):\n \"\"\"\n An instance of [Platform](../utilities.md#hatch.utils.platform.Platform).\n \"\"\"\n return self.__platform\n\n @property\n def data_directory(self):\n \"\"\"\n The [directory](../../config/hatch.md#environments) this plugin should use for storage as a path-like object.\n If the user has not configured one then this will be the same as the\n [isolated data directory](reference.md#hatch.env.plugin.interface.EnvironmentInterface.isolated_data_directory).\n \"\"\"\n return self.__data_directory\n\n @property\n def isolated_data_directory(self):\n \"\"\"\n The default [directory](../../config/hatch.md#environments) reserved exclusively for this plugin as a path-like\n object.\n \"\"\"\n return self.__isolated_data_directory\n\n @property\n def config(self) -> dict:\n \"\"\"\n ```toml config-example\n [tool.hatch.envs.<ENV_NAME>]\n ```\n \"\"\"\n return self.__config\n\n @property\n def system_python(self):\n if self._system_python is None:\n system_python = os.environ.get(AppEnvVars.PYTHON)\n if system_python == 'self':\n system_python = sys.executable\n\n system_python = (\n system_python\n or self.platform.modules.shutil.which('python')\n or self.platform.modules.shutil.which('python3')\n or sys.executable\n )\n if not isabs(system_python):\n system_python = self.platform.modules.shutil.which(system_python)\n\n self._system_python = system_python\n\n return self._system_python\n\n @property\n def env_vars(self) -> dict:\n \"\"\"\n ```toml config-example\n [tool.hatch.envs.<ENV_NAME>.env-vars]\n ```\n \"\"\"\n if self._env_vars is None:\n env_vars = self.config.get('env-vars', {})\n if not isinstance(env_vars, dict):\n message = f'Field `tool.hatch.envs.{self.name}.env-vars` must be a mapping'\n raise TypeError(message)\n\n for key, value in env_vars.items():\n if not isinstance(value, str):\n message = (\n f'Environment variable `{key}` of field `tool.hatch.envs.{self.name}.env-vars` must be a string'\n )\n raise TypeError(message)\n\n new_env_vars = {}\n with self.metadata.context.apply_context(self.context):\n for key, value in env_vars.items():\n new_env_vars[key] = self.metadata.context.format(value)\n\n new_env_vars[AppEnvVars.ENV_ACTIVE] = self.name\n self._env_vars = new_env_vars\n\n return self._env_vars\n\n @property\n def env_include(self) -> list[str]:\n \"\"\"\n ```toml config-example\n [tool.hatch.envs.<ENV_NAME>]\n env-include = [...]\n ```\n \"\"\"\n if self._env_include is None:\n env_include = self.config.get('env-include', [])\n if not isinstance(env_include, list):\n message = f'Field `tool.hatch.envs.{self.name}.env-include` must be an array'\n raise TypeError(message)\n\n for i, pattern in enumerate(env_include, 1):\n if not isinstance(pattern, str):\n message = f'Pattern #{i} of field `tool.hatch.envs.{self.name}.env-include` must be a string'\n raise TypeError(message)\n\n if env_include:\n self._env_include = ['HATCH_BUILD_*', *env_include]\n else:\n self._env_include = env_include\n\n return self._env_include\n\n @property\n def env_exclude(self) -> list[str]:\n \"\"\"\n ```toml config-example\n [tool.hatch.envs.<ENV_NAME>]\n env-exclude = [...]\n ```\n \"\"\"\n if self._env_exclude is None:\n env_exclude = self.config.get('env-exclude', [])\n if not isinstance(env_exclude, list):\n message = f'Field `tool.hatch.envs.{self.name}.env-exclude` must be an array'\n raise TypeError(message)\n\n for i, pattern in enumerate(env_exclude, 1):\n if not isinstance(pattern, str):\n message = f'Pattern #{i} of field `tool.hatch.envs.{self.name}.env-exclude` must be a string'\n raise TypeError(message)\n\n self._env_exclude = env_exclude\n\n return self._env_exclude\n\n @property\n def environment_dependencies_complex(self):\n if self._environment_dependencies_complex is None:\n from packaging.requirements import InvalidRequirement, Requirement\n\n dependencies_complex = []\n with self.apply_context():\n for option in ('dependencies', 'extra-dependencies'):\n dependencies = self.config.get(option, [])\n if not isinstance(dependencies, list):\n message = f'Field `tool.hatch.envs.{self.name}.{option}` must be an array'\n raise TypeError(message)\n\n for i, entry in enumerate(dependencies, 1):\n if not isinstance(entry, str):\n message = (\n f'Dependency #{i} of field `tool.hatch.envs.{self.name}.{option}` must be a string'\n )\n raise TypeError(message)\n\n try:\n dependencies_complex.append(Requirement(self.metadata.context.format(entry)))\n except InvalidRequirement as e:\n message = f'Dependency #{i} of field `tool.hatch.envs.{self.name}.{option}` is invalid: {e}'\n raise ValueError(message) from None\n\n self._environment_dependencies_complex = dependencies_complex\n\n return self._environment_dependencies_complex\n\n @property\n def environment_dependencies(self) -> list[str]:\n \"\"\"\n The list of all [environment dependencies](../../config/environment/overview.md#dependencies).\n \"\"\"\n if self._environment_dependencies is None:\n self._environment_dependencies = [str(dependency) for dependency in self.environment_dependencies_complex]\n\n return self._environment_dependencies\n\n @property\n def dependencies_complex(self):\n if self._dependencies_complex is None:\n all_dependencies_complex = list(self.environment_dependencies_complex)\n\n # Ensure these are checked last to speed up initial environment creation since\n # they will already be installed along with the project\n if (not self.skip_install and self.dev_mode) or self.features:\n from hatch.utils.dep import get_project_dependencies_complex\n\n dependencies_complex, optional_dependencies_complex = get_project_dependencies_complex(self)\n\n if not self.skip_install and self.dev_mode:\n all_dependencies_complex.extend(dependencies_complex.values())\n\n for feature in self.features:\n if feature not in optional_dependencies_complex:\n message = (\n f'Feature `{feature}` of field `tool.hatch.envs.{self.name}.features` is not '\n f'defined in the dynamic field `project.optional-dependencies`'\n )\n raise ValueError(message)\n\n all_dependencies_complex.extend(optional_dependencies_complex[feature].values())\n\n self._dependencies_complex = all_dependencies_complex\n\n return self._dependencies_complex\n\n @property\n def dependencies(self) -> list[str]:\n \"\"\"\n The list of all [project dependencies](../../config/metadata.md#dependencies) (if\n [installed](../../config/environment/overview.md#skip-install) and in\n [dev mode](../../config/environment/overview.md#dev-mode)), selected\n [optional dependencies](../../config/environment/overview.md#features), and\n [environment dependencies](../../config/environment/overview.md#dependencies).\n \"\"\"\n if self._dependencies is None:\n self._dependencies = [str(dependency) for dependency in self.dependencies_complex]\n\n return self._dependencies\n\n @property\n def platforms(self) -> list[str]:\n \"\"\"\n All names are stored as their lower-cased version.\n\n ```toml config-example\n [tool.hatch.envs.<ENV_NAME>]\n platforms = [...]\n ```\n \"\"\"\n if self._platforms is None:\n platforms = self.config.get('platforms', [])\n if not isinstance(platforms, list):\n message = f'Field `tool.hatch.envs.{self.name}.platforms` must be an array'\n raise TypeError(message)\n\n for i, command in enumerate(platforms, 1):\n if not isinstance(command, str):\n message = f'Platform #{i} of field `tool.hatch.envs.{self.name}.platforms` must be a string'\n raise TypeError(message)\n\n self._platforms = [platform.lower() for platform in platforms]\n\n return self._platforms\n\n @property\n def skip_install(self) -> bool:\n \"\"\"\n ```toml config-example\n [tool.hatch.envs.<ENV_NAME>]\n skip-install = ...\n ```\n \"\"\"\n if self._skip_install is None:\n skip_install = self.config.get('skip-install', not self.metadata.has_project_file())\n if not isinstance(skip_install, bool):\n message = f'Field `tool.hatch.envs.{self.name}.skip-install` must be a boolean'\n raise TypeError(message)\n\n self._skip_install = skip_install\n\n return self._skip_install\n\n @property\n def dev_mode(self) -> bool:\n \"\"\"\n ```toml config-example\n [tool.hatch.envs.<ENV_NAME>]\n dev-mode = ...\n ```\n \"\"\"\n if self._dev_mode is None:\n dev_mode = self.config.get('dev-mode', True)\n if not isinstance(dev_mode, bool):\n message = f'Field `tool.hatch.envs.{self.name}.dev-mode` must be a boolean'\n raise TypeError(message)\n\n self._dev_mode = dev_mode\n\n return self._dev_mode\n\n @property\n def features(self):\n if self._features is None:\n from hatchling.metadata.utils import normalize_project_name\n\n features = self.config.get('features', [])\n if not isinstance(features, list):\n message = f'Field `tool.hatch.envs.{self.name}.features` must be an array of strings'\n raise TypeError(message)\n\n all_features = set()\n for i, feature in enumerate(features, 1):\n if not isinstance(feature, str):\n message = f'Feature #{i} of field `tool.hatch.envs.{self.name}.features` must be a string'\n raise TypeError(message)\n\n if not feature:\n message = f'Feature #{i} of field `tool.hatch.envs.{self.name}.features` cannot be an empty string'\n raise ValueError(message)\n\n normalized_feature = (\n feature\n if self.metadata.hatch.metadata.allow_ambiguous_features\n else normalize_project_name(feature)\n )\n if (\n not self.metadata.hatch.metadata.hook_config\n and normalized_feature not in self.metadata.core.optional_dependencies\n ):\n message = (\n f'Feature `{normalized_feature}` of field `tool.hatch.envs.{self.name}.features` is not '\n f'defined in field `project.optional-dependencies`'\n )\n raise ValueError(message)\n\n all_features.add(normalized_feature)\n\n self._features = sorted(all_features)\n\n return self._features\n\n @property\n def description(self) -> str:\n \"\"\"\n ```toml config-example\n [tool.hatch.envs.<ENV_NAME>]\n description = ...\n ```\n \"\"\"\n if self._description is None:\n description = self.config.get('description', '')\n if not isinstance(description, str):\n message = f'Field `tool.hatch.envs.{self.name}.description` must be a string'\n raise TypeError(message)\n\n self._description = description\n\n return self._description\n\n @property\n def scripts(self):\n if self._scripts is None:\n config = {}\n\n # Extra scripts should come first to give less precedence\n for field in ('extra-scripts', 'scripts'):\n script_config = self.config.get(field, {})\n if not isinstance(script_config, dict):\n message = f'Field `tool.hatch.envs.{self.name}.{field}` must be a table'\n raise TypeError(message)\n\n for name, data in script_config.items():\n if ' ' in name:\n message = (\n f'Script name `{name}` in field `tool.hatch.envs.{self.name}.{field}` '\n f'must not contain spaces'\n )\n raise ValueError(message)\n\n commands = []\n\n if isinstance(data, str):\n commands.append(data)\n elif isinstance(data, list):\n for i, command in enumerate(data, 1):\n if not isinstance(command, str):\n message = (\n f'Command #{i} in field `tool.hatch.envs.{self.name}.{field}.{name}` '\n f'must be a string'\n )\n raise TypeError(message)\n\n commands.append(command)\n else:\n message = (\n f'Field `tool.hatch.envs.{self.name}.{field}.{name}` must be '\n f'a string or an array of strings'\n )\n raise TypeError(message)\n\n config[name] = commands\n\n seen = {}\n active = []\n for script_name, commands in config.items():\n commands[:] = expand_script_commands(self.name, script_name, commands, config, seen, active)\n\n self._scripts = config\n\n return self._scripts\n\n @property\n def pre_install_commands(self):\n if self._pre_install_commands is None:\n pre_install_commands = self.config.get('pre-install-commands', [])\n if not isinstance(pre_install_commands, list):\n message = f'Field `tool.hatch.envs.{self.name}.pre-install-commands` must be an array'\n raise TypeError(message)\n\n for i, command in enumerate(pre_install_commands, 1):\n if not isinstance(command, str):\n message = (\n f'Command #{i} of field `tool.hatch.envs.{self.name}.pre-install-commands` must be a string'\n )\n raise TypeError(message)\n\n self._pre_install_commands = list(pre_install_commands)\n\n return self._pre_install_commands\n\n @property\n def post_install_commands(self):\n if self._post_install_commands is None:\n post_install_commands = self.config.get('post-install-commands', [])\n if not isinstance(post_install_commands, list):\n message = f'Field `tool.hatch.envs.{self.name}.post-install-commands` must be an array'\n raise TypeError(message)\n\n for i, command in enumerate(post_install_commands, 1):\n if not isinstance(command, str):\n message = (\n f'Command #{i} of field `tool.hatch.envs.{self.name}.post-install-commands` must be a string'\n )\n raise TypeError(message)\n\n self._post_install_commands = list(post_install_commands)\n\n return self._post_install_commands\n\n def activate(self):\n \"\"\"\n A convenience method called when using the environment as a context manager:\n\n ```python\n with environment:\n ...\n ```\n \"\"\"\n\n def deactivate(self):\n \"\"\"\n A convenience method called after using the environment as a context manager:\n\n ```python\n with environment:\n ...\n ```\n \"\"\"\n\n @abstractmethod\n def find(self):\n \"\"\"\n :material-align-horizontal-left: **REQUIRED** :material-align-horizontal-right:\n\n This should return information about how to locate the environment or represent its ID in\n some way. Additionally, this is expected to return something even if the environment is\n [incompatible](reference.md#hatch.env.plugin.interface.EnvironmentInterface.check_compatibility).\n \"\"\"\n\n @abstractmethod\n def create(self):\n \"\"\"\n :material-align-horizontal-left: **REQUIRED** :material-align-horizontal-right:\n\n This should perform the necessary steps to set up the environment.\n \"\"\"\n\n @abstractmethod\n def remove(self):\n \"\"\"\n :material-align-horizontal-left: **REQUIRED** :material-align-horizontal-right:\n\n This should perform the necessary steps to completely remove the environment from the system and will only\n be triggered manually by users with the [`env remove`](../../cli/reference.md#hatch-env-remove) or\n [`env prune`](../../cli/reference.md#hatch-env-prune) commands.\n\n If the\n [build environment](reference.md#hatch.env.plugin.interface.EnvironmentInterface.build_environment)\n has a caching mechanism, this should remove that as well.\n \"\"\"\n\n @abstractmethod\n def exists(self) -> bool:\n \"\"\"\n :material-align-horizontal-left: **REQUIRED** :material-align-horizontal-right:\n\n This should indicate whether or not the environment has already been created.\n \"\"\"\n\n @abstractmethod\n def install_project(self):\n \"\"\"\n :material-align-horizontal-left: **REQUIRED** :material-align-horizontal-right:\n\n This should install the project in the environment.\n \"\"\"\n\n @abstractmethod\n def install_project_dev_mode(self):\n \"\"\"\n :material-align-horizontal-left: **REQUIRED** :material-align-horizontal-right:\n\n This should install the project in the environment such that the environment\n always reflects the current state of the project.\n \"\"\"\n\n @abstractmethod\n def dependencies_in_sync(self) -> bool:\n \"\"\"\n :material-align-horizontal-left: **REQUIRED** :material-align-horizontal-right:\n\n This should indicate whether or not the environment is compatible with the current\n [dependencies](reference.md#hatch.env.plugin.interface.EnvironmentInterface.dependencies).\n \"\"\"\n\n @abstractmethod\n def sync_dependencies(self):\n \"\"\"\n :material-align-horizontal-left: **REQUIRED** :material-align-horizontal-right:\n\n This should install the\n [dependencies](reference.md#hatch.env.plugin.interface.EnvironmentInterface.dependencies)\n in the environment.\n \"\"\"\n\n def dependency_hash(self):\n \"\"\"\n This should return a hash of the environment's\n [dependencies](reference.md#hatch.env.plugin.interface.EnvironmentInterface.dependencies)\n and any other data that is handled by the\n [sync_dependencies](reference.md#hatch.env.plugin.interface.EnvironmentInterface.sync_dependencies)\n and\n [dependencies_in_sync](reference.md#hatch.env.plugin.interface.EnvironmentInterface.dependencies_in_sync)\n methods.\n \"\"\"\n from hatch.utils.dep import hash_dependencies\n\n return hash_dependencies(self.dependencies_complex)\n\n @contextmanager\n def app_status_creation(self):\n \"\"\"\n See the [life cycle of environments](reference.md#life-cycle).\n \"\"\"\n with self.app.status(f'Creating environment: {self.name}'):\n yield\n\n @contextmanager\n def app_status_pre_installation(self):\n \"\"\"\n See the [life cycle of environments](reference.md#life-cycle).\n \"\"\"\n with self.app.status('Running pre-installation commands'):\n yield\n\n @contextmanager\n def app_status_post_installation(self):\n \"\"\"\n See the [life cycle of environments](reference.md#life-cycle).\n \"\"\"\n with self.app.status('Running post-installation commands'):\n yield\n\n @contextmanager\n def app_status_project_installation(self):\n \"\"\"\n See the [life cycle of environments](reference.md#life-cycle).\n \"\"\"\n if self.dev_mode:\n with self.app.status('Installing project in development mode'):\n yield\n else:\n with self.app.status('Installing project'):\n yield\n\n @contextmanager\n def app_status_dependency_state_check(self):\n \"\"\"\n See the [life cycle of environments](reference.md#life-cycle).\n \"\"\"\n if not self.skip_install and (\n 'dependencies' in self.metadata.dynamic or 'optional-dependencies' in self.metadata.dynamic\n ):\n with self.app.status('Polling dependency state'):\n yield\n else:\n yield\n\n @contextmanager\n def app_status_dependency_installation_check(self):\n \"\"\"\n See the [life cycle of environments](reference.md#life-cycle).\n \"\"\"\n with self.app.status('Checking dependencies'):\n yield\n\n @contextmanager\n def app_status_dependency_synchronization(self):\n \"\"\"\n See the [life cycle of environments](reference.md#life-cycle).\n \"\"\"\n with self.app.status('Syncing dependencies'):\n yield\n\n @contextmanager\n def build_environment(\n self,\n dependencies: list[str], # noqa: ARG002\n ):\n \"\"\"\n This should set up an isolated environment in which to [`build`](../../cli/reference.md#hatch-build) the project\n given a set of dependencies and must be a context manager:\n\n ```python\n with environment.build_environment([...]):\n ...\n ```\n\n The build environment should reflect any\n [environment variables](reference.md#hatch.env.plugin.interface.EnvironmentInterface.get_env_vars)\n the user defined either currently or at the time of\n [creation](reference.md#hatch.env.plugin.interface.EnvironmentInterface.create).\n \"\"\"\n with self.get_env_vars():\n yield\n\n def run_builder(\n self,\n build_environment, # noqa: ARG002\n **kwargs,\n ):\n \"\"\"\n This will be called when the\n [build environment](reference.md#hatch.env.plugin.interface.EnvironmentInterface.build_environment)\n is active:\n\n ```python\n with environment.build_environment([...]) as build_env:\n process = environment.run_builder(build_env, ...)\n ```\n\n This should return the standard library's\n [subprocess.CompletedProcess](https://docs.python.org/3/library/subprocess.html#subprocess.CompletedProcess).\n The command is constructed by passing all keyword arguments to\n [construct_build_command](reference.md#hatch.env.plugin.interface.EnvironmentInterface.construct_build_command).\n\n For an example, open the default implementation below:\n \"\"\"\n return self.platform.run_command(self.construct_build_command(**kwargs))\n\n def build_environment_exists(self): # noqa: PLR6301\n \"\"\"\n If the\n [build environment](reference.md#hatch.env.plugin.interface.EnvironmentInterface.build_environment)\n has a caching mechanism, this should indicate whether or not it has already been created.\n \"\"\"\n return False\n\n def enter_shell(\n self,\n name: str, # noqa: ARG002\n path: str,\n args: Iterable[str],\n ):\n \"\"\"\n Spawn a [shell](../../config/hatch.md#shell) within the environment.\n\n This should either use\n [command_context](reference.md#hatch.env.plugin.interface.EnvironmentInterface.command_context)\n directly or provide the same guarantee.\n \"\"\"\n with self.command_context():\n self.platform.exit_with_command([path, *args])\n\n def run_shell_command(self, command: str, **kwargs):\n \"\"\"\n This should return the standard library's\n [subprocess.CompletedProcess](https://docs.python.org/3/library/subprocess.html#subprocess.CompletedProcess)\n and will always be called when the\n [command_context](reference.md#hatch.env.plugin.interface.EnvironmentInterface.command_context)\n is active, with the expectation of providing the same guarantee.\n \"\"\"\n kwargs.setdefault('shell', True)\n return self.platform.run_command(command, **kwargs)\n\n @contextmanager\n def command_context(self):\n \"\"\"\n A context manager that when active should make executed shell commands reflect any\n [environment variables](reference.md#hatch.env.plugin.interface.EnvironmentInterface.get_env_vars)\n the user defined either currently or at the time of\n [creation](reference.md#hatch.env.plugin.interface.EnvironmentInterface.create).\n\n For an example, open the default implementation below:\n \"\"\"\n with self.get_env_vars():\n yield\n\n def resolve_commands(self, commands: list[str]):\n \"\"\"\n This expands each command into one or more commands based on any\n [scripts](../../config/environment/overview.md#scripts) that the user defined.\n \"\"\"\n for command in commands:\n yield from self.expand_command(command)\n\n def expand_command(self, command):\n possible_script, args, _ignore_exit_code = parse_script_command(command)\n\n # Indicate undefined\n if not args:\n args = None\n\n with self.apply_context():\n if possible_script in self.scripts:\n if args is not None:\n args = self.metadata.context.format(args)\n\n for cmd in self.scripts[possible_script]:\n yield self.metadata.context.format(cmd, args=args).strip()\n else:\n yield self.metadata.context.format(command, args=args).strip()\n\n def construct_build_command( # noqa: PLR6301\n self,\n *,\n directory=None,\n targets=(),\n hooks_only=False,\n no_hooks=False,\n clean=False,\n clean_hooks_after=False,\n clean_only=False,\n ):\n \"\"\"\n This is the canonical way [`build`](../../cli/reference.md#hatch-build) command options are translated to\n a subprocess command issued to [builders](../builder/reference.md).\n \"\"\"\n command = ['python', '-u', '-m', 'hatchling', 'build']\n\n if directory:\n command.extend(('--directory', directory))\n\n if targets:\n for target in targets:\n command.extend(('--target', target))\n\n if hooks_only:\n command.append('--hooks-only')\n\n if no_hooks:\n command.append('--no-hooks')\n\n if clean:\n command.append('--clean')\n\n if clean_hooks_after:\n command.append('--clean-hooks-after')\n\n if clean_only:\n command.append('--clean-only')\n\n return command\n\n def construct_pip_install_command(self, args: list[str]):\n \"\"\"\n A convenience method for constructing a [`pip install`](https://pip.pypa.io/en/stable/cli/pip_install/)\n command with the given verbosity. The default verbosity is set to one less than Hatch's verbosity.\n \"\"\"\n command = ['python', '-u', '-m', 'pip', 'install', '--disable-pip-version-check', '--no-python-version-warning']\n\n # Default to -1 verbosity\n add_verbosity_flag(command, self.verbosity, adjustment=-1)\n\n command.extend(args)\n return command\n\n def join_command_args(self, args: list[str]):\n \"\"\"\n This is used by the [`run`](../../cli/reference.md#hatch-run) command to construct the root command string\n from the received arguments.\n \"\"\"\n return self.platform.join_command_args(args)\n\n def apply_features(self, requirement: str):\n \"\"\"\n A convenience method that applies any user defined [features](../../config/environment/overview.md#features)\n to the given requirement.\n \"\"\"\n if self.features:\n features = ','.join(self.features)\n return f'{requirement}[{features}]'\n\n return requirement\n\n def check_compatibility(self):\n \"\"\"\n This raises an exception if the environment is not compatible with the user's setup. The default behavior\n checks for [platform compatibility](../../config/environment/overview.md#supported-platforms)\n and any method override should keep this check.\n\n This check is never performed if the environment has been\n [created](reference.md#hatch.env.plugin.interface.EnvironmentInterface.create).\n \"\"\"\n if self.platforms and self.platform.name not in self.platforms:\n message = 'unsupported platform'\n raise OSError(message)\n\n def get_env_vars(self) -> EnvVars:\n \"\"\"\n Returns a mapping of environment variables that should be available to the environment. The object can\n be used as a context manager to temporarily apply the environment variables to the current process.\n\n !!! note\n The environment variable `HATCH_ENV_ACTIVE` will always be set to the name of the environment.\n \"\"\"\n return EnvVars(self.env_vars, self.env_include, self.env_exclude)\n\n def get_env_var_option(self, option: str) -> str:\n \"\"\"\n Returns the value of the upper-cased environment variable `HATCH_ENV_TYPE_<PLUGIN_NAME>_<option>`.\n \"\"\"\n return get_env_var_option(plugin_name=self.PLUGIN_NAME, option=option)\n\n def get_context(self):\n \"\"\"\n Returns a subclass of\n [EnvironmentContextFormatter](../utilities.md#hatch.env.context.EnvironmentContextFormatter).\n \"\"\"\n from hatch.env.context import EnvironmentContextFormatter\n\n return EnvironmentContextFormatter(self)\n\n @staticmethod\n def get_option_types() -> dict:\n \"\"\"\n Returns a mapping of supported options to their respective types so that they can be used by\n [overrides](../../config/environment/advanced.md#option-overrides).\n \"\"\"\n return {}\n\n @contextmanager\n def apply_context(self):\n with self.get_env_vars(), self.metadata.context.apply_context(self.context):\n yield\n\n def __enter__(self):\n self.activate()\n return self\n\n def __exit__(self, exc_type, exc_value, traceback):\n self.deactivate()\nPLUGIN_NAME = ''class-attributeinstance-attribute","text":"The name used for selection.
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.app","title":"appproperty","text":"An instance of Application.
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.root","title":"rootproperty","text":"The root of the project tree as a path-like object.
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.name","title":"name: strproperty","text":"The name of the environment.
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.data_directory","title":"data_directoryproperty","text":"The directory this plugin should use for storage as a path-like object. If the user has not configured one then this will be the same as the isolated data directory.
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.isolated_data_directory","title":"isolated_data_directoryproperty","text":"The default directory reserved exclusively for this plugin as a path-like object.
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.config","title":"config: dictproperty","text":"pyproject.toml hatch.toml[tool.hatch.envs.<ENV_NAME>]\n
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.platform","title":"[envs.<ENV_NAME>]\nplatformproperty","text":"An instance of Platform.
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.environment_dependencies","title":"environment_dependencies: list[str]property","text":"The list of all environment dependencies.
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.dependencies","title":"dependencies: list[str]property","text":"The list of all project dependencies (if installed and in dev mode), selected optional dependencies, and environment dependencies.
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.env_vars","title":"env_vars: dictproperty","text":"pyproject.toml hatch.toml[tool.hatch.envs.<ENV_NAME>.env-vars]\n
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.env_include","title":"[envs.<ENV_NAME>.env-vars]\nenv_include: list[str]property","text":"pyproject.toml hatch.toml[tool.hatch.envs.<ENV_NAME>]\nenv-include = [...]\n
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.env_exclude","title":"[envs.<ENV_NAME>]\nenv-include = [...]\nenv_exclude: list[str]property","text":"pyproject.toml hatch.toml[tool.hatch.envs.<ENV_NAME>]\nenv-exclude = [...]\n
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.platforms","title":"[envs.<ENV_NAME>]\nenv-exclude = [...]\nplatforms: list[str]property","text":"All names are stored as their lower-cased version.
pyproject.toml hatch.toml[tool.hatch.envs.<ENV_NAME>]\nplatforms = [...]\n
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.skip_install","title":"[envs.<ENV_NAME>]\nplatforms = [...]\nskip_install: boolproperty","text":"pyproject.toml hatch.toml[tool.hatch.envs.<ENV_NAME>]\nskip-install = ...\n
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.dev_mode","title":"[envs.<ENV_NAME>]\nskip-install = ...\ndev_mode: boolproperty","text":"pyproject.toml hatch.toml[tool.hatch.envs.<ENV_NAME>]\ndev-mode = ...\n
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.description","title":"[envs.<ENV_NAME>]\ndev-mode = ...\ndescription: strproperty","text":"pyproject.toml hatch.toml[tool.hatch.envs.<ENV_NAME>]\ndescription = ...\n
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.find","title":"[envs.<ENV_NAME>]\ndescription = ...\nfind()abstractmethod","text":"REQUIRED
This should return information about how to locate the environment or represent its ID in some way. Additionally, this is expected to return something even if the environment is incompatible.
Source code insrc/hatch/env/plugin/interface.py
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.create","title":"@abstractmethod\ndef find(self):\n \"\"\"\n :material-align-horizontal-left: **REQUIRED** :material-align-horizontal-right:\n\n This should return information about how to locate the environment or represent its ID in\n some way. Additionally, this is expected to return something even if the environment is\n [incompatible](reference.md#hatch.env.plugin.interface.EnvironmentInterface.check_compatibility).\n \"\"\"\ncreate()abstractmethod","text":"REQUIRED
This should perform the necessary steps to set up the environment.
Source code insrc/hatch/env/plugin/interface.py
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.remove","title":"@abstractmethod\ndef create(self):\n \"\"\"\n :material-align-horizontal-left: **REQUIRED** :material-align-horizontal-right:\n\n This should perform the necessary steps to set up the environment.\n \"\"\"\nremove()abstractmethod","text":"REQUIRED
This should perform the necessary steps to completely remove the environment from the system and will only be triggered manually by users with the
env removeorenv prunecommands.If the build environment has a caching mechanism, this should remove that as well.
Source code insrc/hatch/env/plugin/interface.py
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.exists","title":"@abstractmethod\ndef remove(self):\n \"\"\"\n :material-align-horizontal-left: **REQUIRED** :material-align-horizontal-right:\n\n This should perform the necessary steps to completely remove the environment from the system and will only\n be triggered manually by users with the [`env remove`](../../cli/reference.md#hatch-env-remove) or\n [`env prune`](../../cli/reference.md#hatch-env-prune) commands.\n\n If the\n [build environment](reference.md#hatch.env.plugin.interface.EnvironmentInterface.build_environment)\n has a caching mechanism, this should remove that as well.\n \"\"\"\nexists() -> boolabstractmethod","text":"REQUIRED
This should indicate whether or not the environment has already been created.
Source code insrc/hatch/env/plugin/interface.py
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.install_project","title":"@abstractmethod\ndef exists(self) -> bool:\n \"\"\"\n :material-align-horizontal-left: **REQUIRED** :material-align-horizontal-right:\n\n This should indicate whether or not the environment has already been created.\n \"\"\"\ninstall_project()abstractmethod","text":"REQUIRED
This should install the project in the environment.
Source code insrc/hatch/env/plugin/interface.py
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.install_project_dev_mode","title":"@abstractmethod\ndef install_project(self):\n \"\"\"\n :material-align-horizontal-left: **REQUIRED** :material-align-horizontal-right:\n\n This should install the project in the environment.\n \"\"\"\ninstall_project_dev_mode()abstractmethod","text":"REQUIRED
This should install the project in the environment such that the environment always reflects the current state of the project.
Source code insrc/hatch/env/plugin/interface.py
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.dependencies_in_sync","title":"@abstractmethod\ndef install_project_dev_mode(self):\n \"\"\"\n :material-align-horizontal-left: **REQUIRED** :material-align-horizontal-right:\n\n This should install the project in the environment such that the environment\n always reflects the current state of the project.\n \"\"\"\ndependencies_in_sync() -> boolabstractmethod","text":"REQUIRED
This should indicate whether or not the environment is compatible with the current dependencies.
Source code insrc/hatch/env/plugin/interface.py
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.sync_dependencies","title":"@abstractmethod\ndef dependencies_in_sync(self) -> bool:\n \"\"\"\n :material-align-horizontal-left: **REQUIRED** :material-align-horizontal-right:\n\n This should indicate whether or not the environment is compatible with the current\n [dependencies](reference.md#hatch.env.plugin.interface.EnvironmentInterface.dependencies).\n \"\"\"\nsync_dependencies()abstractmethod","text":"REQUIRED
This should install the dependencies in the environment.
Source code insrc/hatch/env/plugin/interface.py
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.dependency_hash","title":"@abstractmethod\ndef sync_dependencies(self):\n \"\"\"\n :material-align-horizontal-left: **REQUIRED** :material-align-horizontal-right:\n\n This should install the\n [dependencies](reference.md#hatch.env.plugin.interface.EnvironmentInterface.dependencies)\n in the environment.\n \"\"\"\ndependency_hash()","text":"This should return a hash of the environment's dependencies and any other data that is handled by the sync_dependencies and dependencies_in_sync methods.
Source code insrc/hatch/env/plugin/interface.py
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.build_environment","title":"def dependency_hash(self):\n \"\"\"\n This should return a hash of the environment's\n [dependencies](reference.md#hatch.env.plugin.interface.EnvironmentInterface.dependencies)\n and any other data that is handled by the\n [sync_dependencies](reference.md#hatch.env.plugin.interface.EnvironmentInterface.sync_dependencies)\n and\n [dependencies_in_sync](reference.md#hatch.env.plugin.interface.EnvironmentInterface.dependencies_in_sync)\n methods.\n \"\"\"\n from hatch.utils.dep import hash_dependencies\n\n return hash_dependencies(self.dependencies_complex)\nbuild_environment(dependencies: list[str])","text":"This should set up an isolated environment in which to
buildthe project given a set of dependencies and must be a context manager:with environment.build_environment([...]):\n ...\nThe build environment should reflect any environment variables the user defined either currently or at the time of creation.
Source code insrc/hatch/env/plugin/interface.py
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.build_environment_exists","title":"@contextmanager\ndef build_environment(\n self,\n dependencies: list[str], # noqa: ARG002\n):\n \"\"\"\n This should set up an isolated environment in which to [`build`](../../cli/reference.md#hatch-build) the project\n given a set of dependencies and must be a context manager:\n\n ```python\n with environment.build_environment([...]):\n ...\n ```\n\n The build environment should reflect any\n [environment variables](reference.md#hatch.env.plugin.interface.EnvironmentInterface.get_env_vars)\n the user defined either currently or at the time of\n [creation](reference.md#hatch.env.plugin.interface.EnvironmentInterface.create).\n \"\"\"\n with self.get_env_vars():\n yield\nbuild_environment_exists()","text":"If the build environment has a caching mechanism, this should indicate whether or not it has already been created.
Source code insrc/hatch/env/plugin/interface.py
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.activate","title":"def build_environment_exists(self): # noqa: PLR6301\n \"\"\"\n If the\n [build environment](reference.md#hatch.env.plugin.interface.EnvironmentInterface.build_environment)\n has a caching mechanism, this should indicate whether or not it has already been created.\n \"\"\"\n return False\nactivate()","text":"A convenience method called when using the environment as a context manager:
Source code inwith environment:\n ...\nsrc/hatch/env/plugin/interface.py
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.deactivate","title":"def activate(self):\n \"\"\"\n A convenience method called when using the environment as a context manager:\n\n ```python\n with environment:\n ...\n ```\n \"\"\"\ndeactivate()","text":"A convenience method called after using the environment as a context manager:
Source code inwith environment:\n ...\nsrc/hatch/env/plugin/interface.py
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.app_status_creation","title":"def deactivate(self):\n \"\"\"\n A convenience method called after using the environment as a context manager:\n\n ```python\n with environment:\n ...\n ```\n \"\"\"\napp_status_creation()","text":"See the life cycle of environments.
Source code insrc/hatch/env/plugin/interface.py
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.app_status_pre_installation","title":"@contextmanager\ndef app_status_creation(self):\n \"\"\"\n See the [life cycle of environments](reference.md#life-cycle).\n \"\"\"\n with self.app.status(f'Creating environment: {self.name}'):\n yield\napp_status_pre_installation()","text":"See the life cycle of environments.
Source code insrc/hatch/env/plugin/interface.py
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.app_status_post_installation","title":"@contextmanager\ndef app_status_pre_installation(self):\n \"\"\"\n See the [life cycle of environments](reference.md#life-cycle).\n \"\"\"\n with self.app.status('Running pre-installation commands'):\n yield\napp_status_post_installation()","text":"See the life cycle of environments.
Source code insrc/hatch/env/plugin/interface.py
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.app_status_project_installation","title":"@contextmanager\ndef app_status_post_installation(self):\n \"\"\"\n See the [life cycle of environments](reference.md#life-cycle).\n \"\"\"\n with self.app.status('Running post-installation commands'):\n yield\napp_status_project_installation()","text":"See the life cycle of environments.
Source code insrc/hatch/env/plugin/interface.py
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.app_status_dependency_state_check","title":"@contextmanager\ndef app_status_project_installation(self):\n \"\"\"\n See the [life cycle of environments](reference.md#life-cycle).\n \"\"\"\n if self.dev_mode:\n with self.app.status('Installing project in development mode'):\n yield\n else:\n with self.app.status('Installing project'):\n yield\napp_status_dependency_state_check()","text":"See the life cycle of environments.
Source code insrc/hatch/env/plugin/interface.py
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.app_status_dependency_installation_check","title":"@contextmanager\ndef app_status_dependency_state_check(self):\n \"\"\"\n See the [life cycle of environments](reference.md#life-cycle).\n \"\"\"\n if not self.skip_install and (\n 'dependencies' in self.metadata.dynamic or 'optional-dependencies' in self.metadata.dynamic\n ):\n with self.app.status('Polling dependency state'):\n yield\n else:\n yield\napp_status_dependency_installation_check()","text":"See the life cycle of environments.
Source code insrc/hatch/env/plugin/interface.py
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.app_status_dependency_synchronization","title":"@contextmanager\ndef app_status_dependency_installation_check(self):\n \"\"\"\n See the [life cycle of environments](reference.md#life-cycle).\n \"\"\"\n with self.app.status('Checking dependencies'):\n yield\napp_status_dependency_synchronization()","text":"See the life cycle of environments.
Source code insrc/hatch/env/plugin/interface.py
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.run_builder","title":"@contextmanager\ndef app_status_dependency_synchronization(self):\n \"\"\"\n See the [life cycle of environments](reference.md#life-cycle).\n \"\"\"\n with self.app.status('Syncing dependencies'):\n yield\nrun_builder(build_environment, **kwargs)","text":"This will be called when the build environment is active:
with environment.build_environment([...]) as build_env:\n process = environment.run_builder(build_env, ...)\nThis should return the standard library's subprocess.CompletedProcess. The command is constructed by passing all keyword arguments to construct_build_command.
For an example, open the default implementation below:
Source code insrc/hatch/env/plugin/interface.py
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.construct_build_command","title":"def run_builder(\n self,\n build_environment, # noqa: ARG002\n **kwargs,\n):\n \"\"\"\n This will be called when the\n [build environment](reference.md#hatch.env.plugin.interface.EnvironmentInterface.build_environment)\n is active:\n\n ```python\n with environment.build_environment([...]) as build_env:\n process = environment.run_builder(build_env, ...)\n ```\n\n This should return the standard library's\n [subprocess.CompletedProcess](https://docs.python.org/3/library/subprocess.html#subprocess.CompletedProcess).\n The command is constructed by passing all keyword arguments to\n [construct_build_command](reference.md#hatch.env.plugin.interface.EnvironmentInterface.construct_build_command).\n\n For an example, open the default implementation below:\n \"\"\"\n return self.platform.run_command(self.construct_build_command(**kwargs))\nconstruct_build_command(*, directory=None, targets=(), hooks_only=False, no_hooks=False, clean=False, clean_hooks_after=False, clean_only=False)","text":"This is the canonical way
Source code inbuildcommand options are translated to a subprocess command issued to builders.src/hatch/env/plugin/interface.py
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.command_context","title":"def construct_build_command( # noqa: PLR6301\n self,\n *,\n directory=None,\n targets=(),\n hooks_only=False,\n no_hooks=False,\n clean=False,\n clean_hooks_after=False,\n clean_only=False,\n):\n \"\"\"\n This is the canonical way [`build`](../../cli/reference.md#hatch-build) command options are translated to\n a subprocess command issued to [builders](../builder/reference.md).\n \"\"\"\n command = ['python', '-u', '-m', 'hatchling', 'build']\n\n if directory:\n command.extend(('--directory', directory))\n\n if targets:\n for target in targets:\n command.extend(('--target', target))\n\n if hooks_only:\n command.append('--hooks-only')\n\n if no_hooks:\n command.append('--no-hooks')\n\n if clean:\n command.append('--clean')\n\n if clean_hooks_after:\n command.append('--clean-hooks-after')\n\n if clean_only:\n command.append('--clean-only')\n\n return command\ncommand_context()","text":"A context manager that when active should make executed shell commands reflect any environment variables the user defined either currently or at the time of creation.
For an example, open the default implementation below:
Source code insrc/hatch/env/plugin/interface.py
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.enter_shell","title":"@contextmanager\ndef command_context(self):\n \"\"\"\n A context manager that when active should make executed shell commands reflect any\n [environment variables](reference.md#hatch.env.plugin.interface.EnvironmentInterface.get_env_vars)\n the user defined either currently or at the time of\n [creation](reference.md#hatch.env.plugin.interface.EnvironmentInterface.create).\n\n For an example, open the default implementation below:\n \"\"\"\n with self.get_env_vars():\n yield\nenter_shell(name: str, path: str, args: Iterable[str])","text":"Spawn a shell within the environment.
This should either use command_context directly or provide the same guarantee.
Source code insrc/hatch/env/plugin/interface.py
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.run_shell_command","title":"def enter_shell(\n self,\n name: str, # noqa: ARG002\n path: str,\n args: Iterable[str],\n):\n \"\"\"\n Spawn a [shell](../../config/hatch.md#shell) within the environment.\n\n This should either use\n [command_context](reference.md#hatch.env.plugin.interface.EnvironmentInterface.command_context)\n directly or provide the same guarantee.\n \"\"\"\n with self.command_context():\n self.platform.exit_with_command([path, *args])\nrun_shell_command(command: str, **kwargs)","text":"This should return the standard library's subprocess.CompletedProcess and will always be called when the command_context is active, with the expectation of providing the same guarantee.
Source code insrc/hatch/env/plugin/interface.py
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.resolve_commands","title":"def run_shell_command(self, command: str, **kwargs):\n \"\"\"\n This should return the standard library's\n [subprocess.CompletedProcess](https://docs.python.org/3/library/subprocess.html#subprocess.CompletedProcess)\n and will always be called when the\n [command_context](reference.md#hatch.env.plugin.interface.EnvironmentInterface.command_context)\n is active, with the expectation of providing the same guarantee.\n \"\"\"\n kwargs.setdefault('shell', True)\n return self.platform.run_command(command, **kwargs)\nresolve_commands(commands: list[str])","text":"This expands each command into one or more commands based on any scripts that the user defined.
Source code insrc/hatch/env/plugin/interface.py
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.get_env_vars","title":"def resolve_commands(self, commands: list[str]):\n \"\"\"\n This expands each command into one or more commands based on any\n [scripts](../../config/environment/overview.md#scripts) that the user defined.\n \"\"\"\n for command in commands:\n yield from self.expand_command(command)\nget_env_vars() -> EnvVars","text":"Returns a mapping of environment variables that should be available to the environment. The object can be used as a context manager to temporarily apply the environment variables to the current process.
Note
The environment variable
Source code inHATCH_ENV_ACTIVEwill always be set to the name of the environment.src/hatch/env/plugin/interface.py
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.apply_features","title":"def get_env_vars(self) -> EnvVars:\n \"\"\"\n Returns a mapping of environment variables that should be available to the environment. The object can\n be used as a context manager to temporarily apply the environment variables to the current process.\n\n !!! note\n The environment variable `HATCH_ENV_ACTIVE` will always be set to the name of the environment.\n \"\"\"\n return EnvVars(self.env_vars, self.env_include, self.env_exclude)\napply_features(requirement: str)","text":"A convenience method that applies any user defined features to the given requirement.
Source code insrc/hatch/env/plugin/interface.py
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.construct_pip_install_command","title":"def apply_features(self, requirement: str):\n \"\"\"\n A convenience method that applies any user defined [features](../../config/environment/overview.md#features)\n to the given requirement.\n \"\"\"\n if self.features:\n features = ','.join(self.features)\n return f'{requirement}[{features}]'\n\n return requirement\nconstruct_pip_install_command(args: list[str])","text":"A convenience method for constructing a
Source code inpip installcommand with the given verbosity. The default verbosity is set to one less than Hatch's verbosity.src/hatch/env/plugin/interface.py
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.join_command_args","title":"def construct_pip_install_command(self, args: list[str]):\n \"\"\"\n A convenience method for constructing a [`pip install`](https://pip.pypa.io/en/stable/cli/pip_install/)\n command with the given verbosity. The default verbosity is set to one less than Hatch's verbosity.\n \"\"\"\n command = ['python', '-u', '-m', 'pip', 'install', '--disable-pip-version-check', '--no-python-version-warning']\n\n # Default to -1 verbosity\n add_verbosity_flag(command, self.verbosity, adjustment=-1)\n\n command.extend(args)\n return command\njoin_command_args(args: list[str])","text":"This is used by the
Source code inruncommand to construct the root command string from the received arguments.src/hatch/env/plugin/interface.py
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.check_compatibility","title":"def join_command_args(self, args: list[str]):\n \"\"\"\n This is used by the [`run`](../../cli/reference.md#hatch-run) command to construct the root command string\n from the received arguments.\n \"\"\"\n return self.platform.join_command_args(args)\ncheck_compatibility()","text":"This raises an exception if the environment is not compatible with the user's setup. The default behavior checks for platform compatibility and any method override should keep this check.
This check is never performed if the environment has been created.
Source code insrc/hatch/env/plugin/interface.py
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.get_option_types","title":"def check_compatibility(self):\n \"\"\"\n This raises an exception if the environment is not compatible with the user's setup. The default behavior\n checks for [platform compatibility](../../config/environment/overview.md#supported-platforms)\n and any method override should keep this check.\n\n This check is never performed if the environment has been\n [created](reference.md#hatch.env.plugin.interface.EnvironmentInterface.create).\n \"\"\"\n if self.platforms and self.platform.name not in self.platforms:\n message = 'unsupported platform'\n raise OSError(message)\nget_option_types() -> dictstaticmethod","text":"Returns a mapping of supported options to their respective types so that they can be used by overrides.
Source code insrc/hatch/env/plugin/interface.py
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.get_env_var_option","title":"@staticmethod\ndef get_option_types() -> dict:\n \"\"\"\n Returns a mapping of supported options to their respective types so that they can be used by\n [overrides](../../config/environment/advanced.md#option-overrides).\n \"\"\"\n return {}\nget_env_var_option(option: str) -> str","text":"Returns the value of the upper-cased environment variable
Source code inHATCH_ENV_TYPE_<PLUGIN_NAME>_<option>.src/hatch/env/plugin/interface.py
"},{"location":"plugins/environment/reference/#hatch.env.plugin.interface.EnvironmentInterface.get_context","title":"def get_env_var_option(self, option: str) -> str:\n \"\"\"\n Returns the value of the upper-cased environment variable `HATCH_ENV_TYPE_<PLUGIN_NAME>_<option>`.\n \"\"\"\n return get_env_var_option(plugin_name=self.PLUGIN_NAME, option=option)\nget_context()","text":"Returns a subclass of EnvironmentContextFormatter.
Source code insrc/hatch/env/plugin/interface.py
"},{"location":"plugins/environment/virtual/","title":"Virtual environment","text":"def get_context(self):\n \"\"\"\n Returns a subclass of\n [EnvironmentContextFormatter](../utilities.md#hatch.env.context.EnvironmentContextFormatter).\n \"\"\"\n from hatch.env.context import EnvironmentContextFormatter\n\n return EnvironmentContextFormatter(self)\nThis uses virtual environments backed by virtualenv or UV.
"},{"location":"plugins/environment/virtual/#configuration","title":"Configuration","text":"The environment plugin name is
pyproject.toml hatch.tomlvirtual.[tool.hatch.envs.<ENV_NAME>]\ntype = \"virtual\"\n
"},{"location":"plugins/environment/virtual/#options","title":"Options","text":"Option Default Description[envs.<ENV_NAME>]\ntype = \"virtual\"\npythonThe version of Python to find on your system and subsequently use to create the environment, defaulting to theHATCH_PYTHONenvironment variable, followed by the normal resolution logic. Setting theHATCH_PYTHONenvironment variable toselfwill force the use of the Python executable Hatch is running on. For more information, see the documentation.python-sources['external', 'internal']This may be set to an array of strings that are either the literalinternalorexternal. External considers only Python executables that are already onPATH. Internal considers only internally managed Python distributions.pathAn explicit path to the virtual environment. The path may be absolute or relative to the project root. Any environments that inherit this option will also use this path. The environment variableHATCH_ENV_TYPE_VIRTUAL_PATHmay be used, which will take precedence.system-packagesfalseWhether or not to give the virtual environment access to the systemsite-packagesdirectoryinstallerpipWhen set touv, UV will be used in place of virtualenv & pip for virtual environment creation and dependency management, respectively. If you intend to provide UV yourself, you may set theHATCH_ENV_TYPE_VIRTUAL_UV_PATHenvironment variable which should be the absolute path to a UV binary. This environment variable implicitly sets theinstalleroption touv(if unset)."},{"location":"plugins/environment/virtual/#location","title":"Location","text":"The location of environments is determined in the following heuristic order:
- The
pathoption - A directory named after the environment within the configured
virtualenvironment directory if the directory resides somewhere within the project root or if it is set to a.virtualenvsdirectory within the user's home directory - Otherwise, environments are stored within the configured
virtualenvironment directory in a deeply nested structure in order to support multiple projects
Additionally, when the
"},{"location":"plugins/environment/virtual/#python-resolution","title":"Python resolution","text":"pathoption is not used, the name of the directory for thedefaultenvironment will be the normalized project name to provide a more meaningful default shell prompt.Virtual environments necessarily require a parent installation of Python. The following rules determine how the parent is resolved.
The Python choice is determined by the
pythonoption followed by theHATCH_PYTHONenvironment variable. If the choice is via the environment variable, then resolution stops and that path is used unconditionally.The resolvers will be based on the
python-sourcesoption and all resolved interpreters will ensure compatibility with the project's defined Python support.If a Python version has been chosen then each resolver will try to find an interpreter that satisfies that version.
If no version has been chosen, then each resolver will try to find a version that matches the version of Python that Hatch is currently running on. If not found then each resolver will try to find the highest compatible version.
Note
Some external Python paths are considered unstable and are ignored during resolution. For example, if Hatch is installed via Homebrew then
sys.executablewill be ignored because the interpreter could change or be removed at any time.Note
When resolution finds a match using an internally managed distribution and an update is available, the latest distribution will automatically be downloaded before environment creation.
"},{"location":"plugins/environment/virtual/#internal-distributions","title":"Internal distributions","text":"The following options are recognized for internal Python resolution.
Tip
You can set custom sources for distributions by setting the
"},{"location":"plugins/environment/virtual/#cpython","title":"CPython","text":"NAMEHATCH_PYTHON_SOURCE_<NAME>environment variable where<NAME>is the uppercased version of the distribution name with periods replaced by underscores e.g.HATCH_PYTHON_SOURCE_PYPY3_10.3.73.83.93.103.113.123.13The source of distributions is the python-build-standalone project.
Some distributions have variants that may be configured. Options may be combined.
Option Platforms Allowed valuesHATCH_PYTHON_VARIANT_CPU- Linux
v1v2v3(default)v4
HATCH_PYTHON_VARIANT_GIL- Linux
- Windows
- macOS
freethreaded
pypy2.7pypy3.9pypy3.10The source of distributions is the PyPy project.
"},{"location":"plugins/environment/virtual/#troubleshooting","title":"Troubleshooting","text":""},{"location":"plugins/environment/virtual/#macos-sip","title":"macOS SIP","text":"If you need to set linker environment variables like those starting with
DYLD_orLD_, any executable secured by System Integrity Protection that is invoked when running commands will not see those environment variable modifications as macOS strips those.Hatch interprets such commands as shell commands but deliberately ignores such paths to protected shells. This workaround suffices for the majority of use cases but there are 2 situations in which it may not:
- There are no unprotected
sh,bash,zsh, norfishexecutables found along PATH. - The desired executable is a project's script, and the location of environments contains spaces or is longer than 1241 characters. In this case
pipand other installers will create such an entry point with a shebang pointing to/bin/sh(which is protected) to avoid shebang limitations. Rather than changing the location, you could invoke the script as e.g.python -m pytest(if the project supports that method of invocation by shipping a__main__.py).
-
The shebang length limit is usually 127 but 3 characters surround the executable path:
#!<EXE_PATH>\\n\u21a9
This is a custom class in a given Python file that inherits from the EnvironmentCollectorInterface.
"},{"location":"plugins/environment-collector/custom/#configuration","title":"Configuration","text":"The environment collector plugin name is
pyproject.toml hatch.tomlcustom.[tool.hatch.env.collectors.custom]\n
"},{"location":"plugins/environment-collector/custom/#options","title":"Options","text":"Option Default Description[env.collectors.custom]\npathhatch_plugins.pyThe path of the Python file"},{"location":"plugins/environment-collector/custom/#example","title":"Example","text":"hatch_plugins.pyfrom hatch.env.collectors.plugin.interface import EnvironmentCollectorInterface\n\n\n class CustomEnvironmentCollector(EnvironmentCollectorInterface):\n ...\nIf multiple subclasses are found, you must define a function named
get_environment_collectorthat returns the desired environment collector.Note
Any defined PLUGIN_NAME is ignored and will always be
"},{"location":"plugins/environment-collector/default/","title":"Default environment collector","text":"custom.This adds the
"},{"location":"plugins/environment-collector/default/#configuration","title":"Configuration","text":"defaultenvironment with type set to virtual and will always be applied.The environment collector plugin name is
pyproject.toml hatch.tomldefault.[tool.hatch.env.collectors.default]\n
"},{"location":"plugins/environment-collector/default/#options","title":"Options","text":"[env.collectors.default]\nThere are no options available currently.
"},{"location":"plugins/environment-collector/reference/","title":"Environment collector plugins","text":"Environment collectors allow for dynamically modifying environments or adding environments beyond those defined in config. Users can override default values provided by each environment.
"},{"location":"plugins/environment-collector/reference/#known-third-party","title":"Known third-party","text":"- hatch-mkdocs - integrate MkDocs and infer dependencies into an env
Any required environment collectors that are not built-in must be manually installed alongside Hatch or listed in the
pyproject.toml hatch.tomltool.hatch.env.requiresarray for automatic management:[tool.hatch.env]\nrequires = [\n \"...\",\n]\n
"},{"location":"plugins/environment-collector/reference/#hatch.env.collectors.plugin.interface.EnvironmentCollectorInterface","title":"[env]\nrequires = [\n \"...\",\n]\nEnvironmentCollectorInterface","text":"Example usage:
plugin.py hooks.pyfrom hatch.env.collectors.plugin.interface import EnvironmentCollectorInterface\n\n\n class SpecialEnvironmentCollector(EnvironmentCollectorInterface):\n PLUGIN_NAME = 'special'\n ...\n
Source code infrom hatchling.plugin import hookimpl\n\n from .plugin import SpecialEnvironmentCollector\n\n\n @hookimpl\n def hatch_register_environment_collector():\n return SpecialEnvironmentCollector\nsrc/hatch/env/collectors/plugin/interface.py
"},{"location":"plugins/environment-collector/reference/#hatch.env.collectors.plugin.interface.EnvironmentCollectorInterface.PLUGIN_NAME","title":"class EnvironmentCollectorInterface:\n \"\"\"\n Example usage:\n\n ```python tab=\"plugin.py\"\n from hatch.env.collectors.plugin.interface import EnvironmentCollectorInterface\n\n\n class SpecialEnvironmentCollector(EnvironmentCollectorInterface):\n PLUGIN_NAME = 'special'\n ...\n ```\n\n ```python tab=\"hooks.py\"\n from hatchling.plugin import hookimpl\n\n from .plugin import SpecialEnvironmentCollector\n\n\n @hookimpl\n def hatch_register_environment_collector():\n return SpecialEnvironmentCollector\n ```\n \"\"\"\n\n PLUGIN_NAME = ''\n \"\"\"The name used for selection.\"\"\"\n\n def __init__(self, root, config):\n self.__root = root\n self.__config = config\n\n @property\n def root(self):\n \"\"\"\n The root of the project tree as a path-like object.\n \"\"\"\n return self.__root\n\n @property\n def config(self) -> dict:\n \"\"\"\n ```toml config-example\n [tool.hatch.env.collectors.<PLUGIN_NAME>]\n ```\n \"\"\"\n return self.__config\n\n def get_initial_config(self) -> dict[str, dict]: # noqa: PLR6301\n \"\"\"\n Returns configuration for environments keyed by the environment or matrix name.\n \"\"\"\n return {}\n\n def finalize_config(self, config: dict[str, dict]):\n \"\"\"\n Finalizes configuration for environments keyed by the environment or matrix name. This will override\n any user-defined settings and any collectors that ran before this call.\n\n This is called before matrices are turned into concrete environments.\n \"\"\"\n\n def finalize_environments(self, config: dict[str, dict]):\n \"\"\"\n Finalizes configuration for environments keyed by the environment name. This will override\n any user-defined settings and any collectors that ran before this call.\n\n This is called after matrices are turned into concrete environments.\n \"\"\"\nPLUGIN_NAME = ''class-attributeinstance-attribute","text":"The name used for selection.
"},{"location":"plugins/environment-collector/reference/#hatch.env.collectors.plugin.interface.EnvironmentCollectorInterface.root","title":"rootproperty","text":"The root of the project tree as a path-like object.
"},{"location":"plugins/environment-collector/reference/#hatch.env.collectors.plugin.interface.EnvironmentCollectorInterface.config","title":"config: dictproperty","text":"pyproject.toml hatch.toml[tool.hatch.env.collectors.<PLUGIN_NAME>]\n
"},{"location":"plugins/environment-collector/reference/#hatch.env.collectors.plugin.interface.EnvironmentCollectorInterface.get_initial_config","title":"[env.collectors.<PLUGIN_NAME>]\nget_initial_config() -> dict[str, dict]","text":"Returns configuration for environments keyed by the environment or matrix name.
Source code insrc/hatch/env/collectors/plugin/interface.py
"},{"location":"plugins/environment-collector/reference/#hatch.env.collectors.plugin.interface.EnvironmentCollectorInterface.finalize_config","title":"def get_initial_config(self) -> dict[str, dict]: # noqa: PLR6301\n \"\"\"\n Returns configuration for environments keyed by the environment or matrix name.\n \"\"\"\n return {}\nfinalize_config(config: dict[str, dict])","text":"Finalizes configuration for environments keyed by the environment or matrix name. This will override any user-defined settings and any collectors that ran before this call.
This is called before matrices are turned into concrete environments.
Source code insrc/hatch/env/collectors/plugin/interface.py
"},{"location":"plugins/environment-collector/reference/#hatch.env.collectors.plugin.interface.EnvironmentCollectorInterface.finalize_environments","title":"def finalize_config(self, config: dict[str, dict]):\n \"\"\"\n Finalizes configuration for environments keyed by the environment or matrix name. This will override\n any user-defined settings and any collectors that ran before this call.\n\n This is called before matrices are turned into concrete environments.\n \"\"\"\nfinalize_environments(config: dict[str, dict])","text":"Finalizes configuration for environments keyed by the environment name. This will override any user-defined settings and any collectors that ran before this call.
This is called after matrices are turned into concrete environments.
Source code insrc/hatch/env/collectors/plugin/interface.py
"},{"location":"plugins/metadata-hook/custom/","title":"Custom metadata hook","text":"def finalize_environments(self, config: dict[str, dict]):\n \"\"\"\n Finalizes configuration for environments keyed by the environment name. This will override\n any user-defined settings and any collectors that ran before this call.\n\n This is called after matrices are turned into concrete environments.\n \"\"\"\nThis is a custom class in a given Python file that inherits from the MetadataHookInterface.
"},{"location":"plugins/metadata-hook/custom/#configuration","title":"Configuration","text":"The metadata hook plugin name is
pyproject.toml hatch.tomlcustom.[tool.hatch.metadata.hooks.custom]\n
"},{"location":"plugins/metadata-hook/custom/#options","title":"Options","text":"Option Default Description[metadata.hooks.custom]\npathhatch_build.pyThe path of the Python file"},{"location":"plugins/metadata-hook/custom/#example","title":"Example","text":"hatch_build.pyfrom hatchling.metadata.plugin.interface import MetadataHookInterface\n\n\nclass CustomMetadataHook(MetadataHookInterface):\n ...\nIf multiple subclasses are found, you must define a function named
get_metadata_hookthat returns the desired build hook.Note
Any defined PLUGIN_NAME is ignored and will always be
"},{"location":"plugins/metadata-hook/reference/","title":"Metadata hook plugins","text":"custom.Metadata hooks allow for the modification of project metadata after it has been loaded.
"},{"location":"plugins/metadata-hook/reference/#known-third-party","title":"Known third-party","text":"- hatch-docstring-description - set the project description using docstrings
- hatch-fancy-pypi-readme - dynamically construct the README
- hatch-nodejs-version - uses fields from NodeJS
package.jsonfiles - hatch-odoo - determine dependencies based on manifests of Odoo add-ons
- hatch-requirements-txt - read project dependencies from
requirements.txtfiles - UniDep - for unified
pipandcondadependency management using a singlerequirements.yamlfile for both
MetadataHookInterface","text":"Example usage:
plugin.py hooks.pyfrom hatchling.metadata.plugin.interface import MetadataHookInterface\n\n\nclass SpecialMetadataHook(MetadataHookInterface):\n PLUGIN_NAME = 'special'\n ...\n
Source code infrom hatchling.plugin import hookimpl\n\nfrom .plugin import SpecialMetadataHook\n\n\n@hookimpl\ndef hatch_register_metadata_hook():\n return SpecialMetadataHook\nbackend/src/hatchling/metadata/plugin/interface.py
"},{"location":"plugins/metadata-hook/reference/#hatchling.metadata.plugin.interface.MetadataHookInterface.PLUGIN_NAME","title":"class MetadataHookInterface(ABC): # no cov\n \"\"\"\n Example usage:\n\n ```python tab=\"plugin.py\"\n from hatchling.metadata.plugin.interface import MetadataHookInterface\n\n\n class SpecialMetadataHook(MetadataHookInterface):\n PLUGIN_NAME = 'special'\n ...\n ```\n\n ```python tab=\"hooks.py\"\n from hatchling.plugin import hookimpl\n\n from .plugin import SpecialMetadataHook\n\n\n @hookimpl\n def hatch_register_metadata_hook():\n return SpecialMetadataHook\n ```\n \"\"\"\n\n PLUGIN_NAME = ''\n \"\"\"The name used for selection.\"\"\"\n\n def __init__(self, root: str, config: dict) -> None:\n self.__root = root\n self.__config = config\n\n @property\n def root(self) -> str:\n \"\"\"\n The root of the project tree.\n \"\"\"\n return self.__root\n\n @property\n def config(self) -> dict:\n \"\"\"\n The hook configuration.\n\n ```toml config-example\n [tool.hatch.metadata.hooks.<PLUGIN_NAME>]\n ```\n \"\"\"\n return self.__config\n\n @abstractmethod\n def update(self, metadata: dict) -> None:\n \"\"\"\n This updates the metadata mapping of the `project` table in-place.\n \"\"\"\n\n def get_known_classifiers(self) -> list[str]: # noqa: PLR6301\n \"\"\"\n This returns extra classifiers that should be considered valid in addition to the ones known to PyPI.\n \"\"\"\n return []\nPLUGIN_NAME = ''class-attributeinstance-attribute","text":"The name used for selection.
"},{"location":"plugins/metadata-hook/reference/#hatchling.metadata.plugin.interface.MetadataHookInterface.root","title":"root: strproperty","text":"The root of the project tree.
"},{"location":"plugins/metadata-hook/reference/#hatchling.metadata.plugin.interface.MetadataHookInterface.config","title":"config: dictproperty","text":"The hook configuration.
pyproject.toml hatch.toml[tool.hatch.metadata.hooks.<PLUGIN_NAME>]\n
"},{"location":"plugins/metadata-hook/reference/#hatchling.metadata.plugin.interface.MetadataHookInterface.update","title":"[metadata.hooks.<PLUGIN_NAME>]\nupdate(metadata: dict) -> Noneabstractmethod","text":"This updates the metadata mapping of the
Source code inprojecttable in-place.backend/src/hatchling/metadata/plugin/interface.py
"},{"location":"plugins/metadata-hook/reference/#hatchling.metadata.plugin.interface.MetadataHookInterface.get_known_classifiers","title":"@abstractmethod\ndef update(self, metadata: dict) -> None:\n \"\"\"\n This updates the metadata mapping of the `project` table in-place.\n \"\"\"\nget_known_classifiers() -> list[str]","text":"This returns extra classifiers that should be considered valid in addition to the ones known to PyPI.
Source code inbackend/src/hatchling/metadata/plugin/interface.py
"},{"location":"plugins/publisher/package-index/","title":"Index publisher","text":"def get_known_classifiers(self) -> list[str]: # noqa: PLR6301\n \"\"\"\n This returns extra classifiers that should be considered valid in addition to the ones known to PyPI.\n \"\"\"\n return []\nSee the documentation for publishing.
"},{"location":"plugins/publisher/package-index/#options","title":"Options","text":"Flag Config name Description-r/--reporepoThe repository with which to publish artifacts-u/--useruserThe user with which to authenticate-a/--authauthThe credentials to use for authentication--ca-certca-certThe path to a CA bundle--client-certclient-certThe path to a client certificate, optionally containing the private key--client-keyclient-keyThe path to the client certificate's private keyreposA table of named repositories to their respective options"},{"location":"plugins/publisher/package-index/#configuration","title":"Configuration","text":"The publisher plugin name is
config.tomlindex.
"},{"location":"plugins/publisher/package-index/#repositories","title":"Repositories","text":"[publish.index]\nAll top-level options can be overridden per repository using the
config.tomlrepostable with a requiredurlattribute for each repository. The following shows the default configuration:[publish.index.repos.main]\nurl = \"https://upload.pypi.org/legacy/\"\n\n[publish.index.repos.test]\nurl = \"https://test.pypi.org/legacy/\"\nThe
"},{"location":"plugins/publisher/package-index/#confirmation-prompt","title":"Confirmation prompt","text":"repoandreposoptions have no effect.You can require a confirmation prompt or use of the
config.toml pyproject.toml hatch.toml-y/--yesflag by setting publishers'disableoption totruein either Hatch's config file or project-specific configuration (which takes precedence):[publish.index]\ndisable = true\n[tool.hatch.publish.index]\ndisable = true\n
"},{"location":"plugins/publisher/reference/","title":"Publisher plugins","text":""},{"location":"plugins/publisher/reference/#known-third-party","title":"Known third-party","text":"[publish.index]\ndisable = true\n- hatch-aws-publisher - publish AWS Lambda functions with SAM
PublisherInterface","text":"Example usage:
plugin.py hooks.pyfrom hatch.publish.plugin.interface import PublisherInterface\n\n\n class SpecialPublisher(PublisherInterface):\n PLUGIN_NAME = 'special'\n ...\n
Source code infrom hatchling.plugin import hookimpl\n\n from .plugin import SpecialPublisher\n\n\n @hookimpl\n def hatch_register_publisher():\n return SpecialPublisher\nsrc/hatch/publish/plugin/interface.py
"},{"location":"plugins/publisher/reference/#hatch.publish.plugin.interface.PublisherInterface.PLUGIN_NAME","title":"class PublisherInterface(ABC):\n \"\"\"\n Example usage:\n\n ```python tab=\"plugin.py\"\n from hatch.publish.plugin.interface import PublisherInterface\n\n\n class SpecialPublisher(PublisherInterface):\n PLUGIN_NAME = 'special'\n ...\n ```\n\n ```python tab=\"hooks.py\"\n from hatchling.plugin import hookimpl\n\n from .plugin import SpecialPublisher\n\n\n @hookimpl\n def hatch_register_publisher():\n return SpecialPublisher\n ```\n \"\"\"\n\n PLUGIN_NAME = ''\n \"\"\"The name used for selection.\"\"\"\n\n def __init__(self, app, root, cache_dir, project_config, plugin_config):\n self.__app = app\n self.__root = root\n self.__cache_dir = cache_dir\n self.__project_config = project_config\n self.__plugin_config = plugin_config\n\n self.__disable = None\n\n @property\n def app(self):\n \"\"\"\n An instance of [Application](../utilities.md#hatchling.bridge.app.Application).\n \"\"\"\n return self.__app\n\n @property\n def root(self):\n \"\"\"\n The root of the project tree as a path-like object.\n \"\"\"\n return self.__root\n\n @property\n def cache_dir(self):\n \"\"\"\n The directory reserved exclusively for this plugin as a path-like object.\n \"\"\"\n return self.__cache_dir\n\n @property\n def project_config(self) -> dict:\n \"\"\"\n ```toml config-example\n [tool.hatch.publish.<PLUGIN_NAME>]\n ```\n \"\"\"\n return self.__project_config\n\n @property\n def plugin_config(self) -> dict:\n \"\"\"\n This is defined in Hatch's [config file](../../config/hatch.md).\n\n ```toml tab=\"config.toml\"\n [publish.<PLUGIN_NAME>]\n ```\n \"\"\"\n return self.__plugin_config\n\n @property\n def disable(self):\n \"\"\"\n Whether this plugin is disabled, thus requiring confirmation when publishing. Local\n [project configuration](reference.md#hatch.publish.plugin.interface.PublisherInterface.project_config)\n takes precedence over global\n [plugin configuration](reference.md#hatch.publish.plugin.interface.PublisherInterface.plugin_config).\n \"\"\"\n if self.__disable is None:\n if 'disable' in self.project_config:\n disable = self.project_config['disable']\n if not isinstance(disable, bool):\n message = f'Field `tool.hatch.publish.{self.PLUGIN_NAME}.disable` must be a boolean'\n raise TypeError(message)\n else:\n disable = self.plugin_config.get('disable', False)\n if not isinstance(disable, bool):\n message = f'Global plugin configuration `publish.{self.PLUGIN_NAME}.disable` must be a boolean'\n raise TypeError(message)\n\n self.__disable = disable\n\n return self.__disable\n\n @abstractmethod\n def publish(self, artifacts: list[str], options: dict):\n \"\"\"\n :material-align-horizontal-left: **REQUIRED** :material-align-horizontal-right:\n\n This is called directly by the [`publish`](../../cli/reference.md#hatch-publish) command\n with the arguments and options it receives.\n \"\"\"\nPLUGIN_NAME = ''class-attributeinstance-attribute","text":"The name used for selection.
"},{"location":"plugins/publisher/reference/#hatch.publish.plugin.interface.PublisherInterface.app","title":"appproperty","text":"An instance of Application.
"},{"location":"plugins/publisher/reference/#hatch.publish.plugin.interface.PublisherInterface.root","title":"rootproperty","text":"The root of the project tree as a path-like object.
"},{"location":"plugins/publisher/reference/#hatch.publish.plugin.interface.PublisherInterface.cache_dir","title":"cache_dirproperty","text":"The directory reserved exclusively for this plugin as a path-like object.
"},{"location":"plugins/publisher/reference/#hatch.publish.plugin.interface.PublisherInterface.project_config","title":"project_config: dictproperty","text":"pyproject.toml hatch.toml[tool.hatch.publish.<PLUGIN_NAME>]\n
"},{"location":"plugins/publisher/reference/#hatch.publish.plugin.interface.PublisherInterface.plugin_config","title":"[publish.<PLUGIN_NAME>]\nplugin_config: dictproperty","text":"This is defined in Hatch's config file.
config.toml
"},{"location":"plugins/publisher/reference/#hatch.publish.plugin.interface.PublisherInterface.disable","title":"[publish.<PLUGIN_NAME>]\ndisableproperty","text":"Whether this plugin is disabled, thus requiring confirmation when publishing. Local project configuration takes precedence over global plugin configuration.
"},{"location":"plugins/publisher/reference/#hatch.publish.plugin.interface.PublisherInterface.publish","title":"publish(artifacts: list[str], options: dict)abstractmethod","text":"REQUIRED
This is called directly by the
Source code inpublishcommand with the arguments and options it receives.src/hatch/publish/plugin/interface.py
"},{"location":"plugins/version-scheme/reference/","title":"Version scheme plugins","text":""},{"location":"plugins/version-scheme/reference/#known-third-party","title":"Known third-party","text":"@abstractmethod\ndef publish(self, artifacts: list[str], options: dict):\n \"\"\"\n :material-align-horizontal-left: **REQUIRED** :material-align-horizontal-right:\n\n This is called directly by the [`publish`](../../cli/reference.md#hatch-publish) command\n with the arguments and options it receives.\n \"\"\"\n- hatch-semver - uses semantic versioning
VersionSchemeInterface","text":"Example usage:
plugin.py hooks.pyfrom hatchling.version.scheme.plugin.interface import VersionSchemeInterface\n\n\nclass SpecialVersionScheme(VersionSchemeInterface):\n PLUGIN_NAME = 'special'\n ...\n
Source code infrom hatchling.plugin import hookimpl\n\nfrom .plugin import SpecialVersionScheme\n\n\n@hookimpl\ndef hatch_register_version_scheme():\n return SpecialVersionScheme\nbackend/src/hatchling/version/scheme/plugin/interface.py
"},{"location":"plugins/version-scheme/reference/#hatchling.version.scheme.plugin.interface.VersionSchemeInterface.PLUGIN_NAME","title":"class VersionSchemeInterface(ABC): # no cov\n \"\"\"\n Example usage:\n\n ```python tab=\"plugin.py\"\n from hatchling.version.scheme.plugin.interface import VersionSchemeInterface\n\n\n class SpecialVersionScheme(VersionSchemeInterface):\n PLUGIN_NAME = 'special'\n ...\n ```\n\n ```python tab=\"hooks.py\"\n from hatchling.plugin import hookimpl\n\n from .plugin import SpecialVersionScheme\n\n\n @hookimpl\n def hatch_register_version_scheme():\n return SpecialVersionScheme\n ```\n \"\"\"\n\n PLUGIN_NAME = ''\n \"\"\"The name used for selection.\"\"\"\n\n def __init__(self, root: str, config: dict) -> None:\n self.__root = root\n self.__config = config\n\n @property\n def root(self) -> str:\n \"\"\"\n The root of the project tree as a string.\n \"\"\"\n return self.__root\n\n @property\n def config(self) -> dict:\n \"\"\"\n ```toml config-example\n [tool.hatch.version]\n ```\n \"\"\"\n return self.__config\n\n @abstractmethod\n def update(self, desired_version: str, original_version: str, version_data: dict) -> str:\n \"\"\"\n This should return a normalized form of the desired version and verify that it\n is higher than the original version.\n \"\"\"\nPLUGIN_NAME = ''class-attributeinstance-attribute","text":"The name used for selection.
"},{"location":"plugins/version-scheme/reference/#hatchling.version.scheme.plugin.interface.VersionSchemeInterface.root","title":"root: strproperty","text":"The root of the project tree as a string.
"},{"location":"plugins/version-scheme/reference/#hatchling.version.scheme.plugin.interface.VersionSchemeInterface.config","title":"config: dictproperty","text":"pyproject.toml hatch.toml[tool.hatch.version]\n
"},{"location":"plugins/version-scheme/reference/#hatchling.version.scheme.plugin.interface.VersionSchemeInterface.update","title":"[version]\nupdate(desired_version: str, original_version: str, version_data: dict) -> strabstractmethod","text":"This should return a normalized form of the desired version and verify that it is higher than the original version.
Source code inbackend/src/hatchling/version/scheme/plugin/interface.py
"},{"location":"plugins/version-scheme/standard/","title":"Standard version scheme","text":"@abstractmethod\ndef update(self, desired_version: str, original_version: str, version_data: dict) -> str:\n \"\"\"\n This should return a normalized form of the desired version and verify that it\n is higher than the original version.\n \"\"\"\nSee the documentation for versioning.
"},{"location":"plugins/version-scheme/standard/#configuration","title":"Configuration","text":"The version scheme plugin name is
pyproject.toml hatch.tomlstandard.[tool.hatch.version]\nscheme = \"standard\"\n
"},{"location":"plugins/version-scheme/standard/#options","title":"Options","text":"Option Description[version]\nscheme = \"standard\"\nvalidate-bumpWhen setting a specific version, this determines whether to check that the new version is higher than the original. The default istrue."},{"location":"plugins/version-source/code/","title":"Code version source","text":""},{"location":"plugins/version-source/code/#updates","title":"Updates","text":"Setting the version is not supported.
"},{"location":"plugins/version-source/code/#configuration","title":"Configuration","text":"The version source plugin name is
pyproject.toml hatch.tomlcode.[tool.hatch.version]\nsource = \"code\"\n
"},{"location":"plugins/version-source/code/#options","title":"Options","text":"Option Description[version]\nsource = \"code\"\npath(required) A relative path to a Python file or extension module that will be loadedexpressionA Python expression that when evaluated in the context of the loaded file returns the version. The default expression is simply__version__.search-pathsA list of relative paths to directories that will be prepended to Python's search path"},{"location":"plugins/version-source/code/#missing-imports","title":"Missing imports","text":"If the chosen path imports another module in your project, then you'll need to use absolute imports coupled with the
src/pkg/__init__.pysearch-pathsoption. For example, say you need to load the following file:from ._version import get_version\n\n __version__ = get_version()\nYou should change it to:
src/pkg/__init__.pyfrom pkg._version import get_version\n\n __version__ = get_version()\nand the configuration would become:
pyproject.toml hatch.toml[tool.hatch.version]\nsource = \"code\"\npath = \"src/pkg/__init__.py\"\nsearch-paths = [\"src\"]\n
"},{"location":"plugins/version-source/env/","title":"Environment version source","text":"[version]\nsource = \"code\"\npath = \"src/pkg/__init__.py\"\nsearch-paths = [\"src\"]\nRetrieves the version from an environment variable. This can be useful in build pipelines where the version is set by an external trigger.
"},{"location":"plugins/version-source/env/#updates","title":"Updates","text":"Setting the version is not supported.
"},{"location":"plugins/version-source/env/#configuration","title":"Configuration","text":"The version source plugin name is
pyproject.toml hatch.tomlenv.[tool.hatch.version]\nsource = \"env\"\n
"},{"location":"plugins/version-source/env/#options","title":"Options","text":"Option Description[version]\nsource = \"env\"\nvariable(required) The name of the environment variable"},{"location":"plugins/version-source/reference/","title":"Version source plugins","text":""},{"location":"plugins/version-source/reference/#known-third-party","title":"Known third-party","text":"- hatch-vcs - uses your preferred version control system (like Git)
- hatch-nodejs-version - uses the
versionfield of NodeJSpackage.jsonfiles - hatch-regex-commit - automatically creates a Git commit and tag after version bumping
- versioningit - determines version from Git or Mercurial tags, with customizable version formatting
VersionSourceInterface","text":"Example usage:
plugin.py hooks.pyfrom hatchling.version.source.plugin.interface import VersionSourceInterface\n\n\nclass SpecialVersionSource(VersionSourceInterface):\n PLUGIN_NAME = 'special'\n ...\n
Source code infrom hatchling.plugin import hookimpl\n\nfrom .plugin import SpecialVersionSource\n\n\n@hookimpl\ndef hatch_register_version_source():\n return SpecialVersionSource\nbackend/src/hatchling/version/source/plugin/interface.py
"},{"location":"plugins/version-source/reference/#hatchling.version.source.plugin.interface.VersionSourceInterface.PLUGIN_NAME","title":"class VersionSourceInterface(ABC): # no cov\n \"\"\"\n Example usage:\n\n ```python tab=\"plugin.py\"\n from hatchling.version.source.plugin.interface import VersionSourceInterface\n\n\n class SpecialVersionSource(VersionSourceInterface):\n PLUGIN_NAME = 'special'\n ...\n ```\n\n ```python tab=\"hooks.py\"\n from hatchling.plugin import hookimpl\n\n from .plugin import SpecialVersionSource\n\n\n @hookimpl\n def hatch_register_version_source():\n return SpecialVersionSource\n ```\n \"\"\"\n\n PLUGIN_NAME = ''\n \"\"\"The name used for selection.\"\"\"\n\n def __init__(self, root: str, config: dict) -> None:\n self.__root = root\n self.__config = config\n\n @property\n def root(self) -> str:\n \"\"\"\n The root of the project tree as a string.\n \"\"\"\n return self.__root\n\n @property\n def config(self) -> dict:\n \"\"\"\n ```toml config-example\n [tool.hatch.version]\n ```\n \"\"\"\n return self.__config\n\n @abstractmethod\n def get_version_data(self) -> dict:\n \"\"\"\n This should return a mapping with a `version` key representing the current version of the project and will be\n displayed when invoking the [`version`](../../cli/reference.md#hatch-version) command without any arguments.\n\n The mapping can contain anything else and will be passed to\n [set_version](reference.md#hatchling.version.source.plugin.interface.VersionSourceInterface.set_version)\n when updating the version.\n \"\"\"\n\n def set_version(self, version: str, version_data: dict) -> None:\n \"\"\"\n This should update the version to the first argument with the data provided during retrieval.\n \"\"\"\n raise NotImplementedError\nPLUGIN_NAME = ''class-attributeinstance-attribute","text":"The name used for selection.
"},{"location":"plugins/version-source/reference/#hatchling.version.source.plugin.interface.VersionSourceInterface.root","title":"root: strproperty","text":"The root of the project tree as a string.
"},{"location":"plugins/version-source/reference/#hatchling.version.source.plugin.interface.VersionSourceInterface.config","title":"config: dictproperty","text":"pyproject.toml hatch.toml[tool.hatch.version]\n
"},{"location":"plugins/version-source/reference/#hatchling.version.source.plugin.interface.VersionSourceInterface.get_version_data","title":"[version]\nget_version_data() -> dictabstractmethod","text":"This should return a mapping with a
versionkey representing the current version of the project and will be displayed when invoking theversioncommand without any arguments.The mapping can contain anything else and will be passed to set_version when updating the version.
Source code inbackend/src/hatchling/version/source/plugin/interface.py
"},{"location":"plugins/version-source/reference/#hatchling.version.source.plugin.interface.VersionSourceInterface.set_version","title":"@abstractmethod\ndef get_version_data(self) -> dict:\n \"\"\"\n This should return a mapping with a `version` key representing the current version of the project and will be\n displayed when invoking the [`version`](../../cli/reference.md#hatch-version) command without any arguments.\n\n The mapping can contain anything else and will be passed to\n [set_version](reference.md#hatchling.version.source.plugin.interface.VersionSourceInterface.set_version)\n when updating the version.\n \"\"\"\nset_version(version: str, version_data: dict) -> None","text":"This should update the version to the first argument with the data provided during retrieval.
Source code inbackend/src/hatchling/version/source/plugin/interface.py
"},{"location":"plugins/version-source/regex/","title":"Regex version source","text":"def set_version(self, version: str, version_data: dict) -> None:\n \"\"\"\n This should update the version to the first argument with the data provided during retrieval.\n \"\"\"\n raise NotImplementedError\nSee the documentation for versioning.
"},{"location":"plugins/version-source/regex/#updates","title":"Updates","text":"Setting the version is supported.
"},{"location":"plugins/version-source/regex/#configuration","title":"Configuration","text":"The version source plugin name is
pyproject.toml hatch.tomlregex.[tool.hatch.version]\nsource = \"regex\"\n
"},{"location":"plugins/version-source/regex/#options","title":"Options","text":"Option Description[version]\nsource = \"regex\"\npath(required) A relative path to a file containing the project's versionpatternA regular expression that has a named group calledversionthat represents the version. The default pattern looks for a variable named__version__orVERSIONthat is set to a string containing the version, optionally prefixed with the lowercase letterv."},{"location":"tutorials/environment/basic-usage/","title":"Managing environments","text":"Hatch environments are isolated workspaces that can be used for project tasks including running tests, building documentation and running code formatters and linters.
"},{"location":"tutorials/environment/basic-usage/#the-default-environment","title":"The default environment","text":"When you start using Hatch, you can create the
defaultenvironment. To do this use theenv createcommand:hatch env create\nThis will not only create will the
defaultenvironment for you to work in but will also install your project in dev mode in thisdefaultenvironment.Tip
You never need to manually create environments as spawning a shell or running commands within one will automatically trigger creation.
"},{"location":"tutorials/environment/basic-usage/#using-the-default-environment","title":"Using the default environment","text":"Hatch will always use the
defaultenvironment if an environment is not chosen explicitly when running a command.For instance, the following shows how to get version information for the Python in use.
"},{"location":"tutorials/environment/basic-usage/#configure-the-default-environment","title":"Configure the default environment","text":"$ hatch run python -V\nPython 3.12.1\nYou can customize the tools that are installed into the
pyproject.toml hatch.tomldefaultenvironment by adding a table calledtool.hatch.envs.defaultto yourpyproject.tomlfile. Below is an example of adding the dependenciespydanticandnumpyto thedefaultenvironment.[tool.hatch.envs.default]\ndependencies = [\n \"pydantic\",\n \"numpy\",\n]\n[envs.default]\ndependencies = [\n \"pydantic\",\n \"numpy\",\n]\nYou can declare versions for your dependencies as well within this configuration.
pyproject.toml hatch.toml[tool.hatch.envs.default]\ndependencies = [\n \"pydantic>=2.0\",\n \"numpy\",\n]\n
"},{"location":"tutorials/environment/basic-usage/#create-custom-environment","title":"Create custom environment","text":"[envs.default]\ndependencies = [\n \"pydantic>=2.0\",\n \"numpy\",\n]\nYou can create custom environments in Hatch by adding a section to your
pyproject.toml hatch.tomlpyproject.tomlfile[tool.hatch.envs.<ENV_NAME>]. Below you define an environment calledtestand you add thepytestandpytest-covdependencies to that environment's configuration.[tool.hatch.envs.test]\ndependencies = [\n \"pytest\",\n \"pytest-cov\"\n]\n[envs.test]\ndependencies = [\n \"pytest\",\n \"pytest-cov\"\n]\nThe first time that you call the test environment, Hatch will:
- Create the environment
- Install your project into that environment in dev mode (by default) along with its dependencies.
- Install the environment's dependencies
Hatch offers a unique environment feature that allows you run a specific command within a specific environment rather than needing to activate the environment as you would using a tool such as Conda or venv.
For instance, if you define an environment called
testthat contains the dependencies from the previous section, you can run thepytestcommand from thetestenvironment using the syntax:hatch run <ENV_NAME>:command\nTo access the
testenvironment and runpytest, you can run:$ hatch run test:pytest\n============================== test session starts ===============================\nplatform darwin -- Python 3.12.1, pytest-7.4.4, pluggy-1.3.0\nrootdir: /your/path/to/yourproject\ncollected 0 items\nNote
"},{"location":"tutorials/environment/basic-usage/#view-current-environments","title":"View current environments","text":"test:pytestrepresents the name of the environment to call (test) and the command to run (pytest).Above you defined and created a new test environment in your
pyproject.tomlfile. You can now use theenv showcommand to see both the currently created environments and the dependencies in each environment.$ hatch env show\n Standalone\n\u250f\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2533\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2533\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2513\n\u2503 Name \u2503 Type \u2503 Dependencies \u2503\n\u2521\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2547\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2547\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2529\n\u2502 default \u2502 virtual \u2502 \u2502\n\u251c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502 test \u2502 virtual \u2502 pytest \u2502\n\u2502 \u2502 \u2502 pytest-cov \u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\nNote
The output may have more columns depending on your environment configuration.
"},{"location":"tutorials/environment/basic-usage/#locating-environments","title":"Locating environments","text":"To see where your current environment is located you can use the
env findcommand.$ hatch env find test\n/your/path/Application Support/hatch/env/virtual/yourproject/twO2iQR3/test\nNote
That path is what you would see on macOS but differs for each platform, and is configurable.
"},{"location":"tutorials/environment/basic-usage/#launching-a-shell-within-a-specific-environment","title":"Launching a shell within a specific environment","text":"If you wish to launch a shell for a specific environment that you have created, like the previous
testenvironment, you can use:hatch -e test shell\nOnce the environment is active, you can run commands like you would in any Python environment.
Notice below that when running
pip listin the test environment, you can see:- That you package is installed in editable mode.
- That the environment contains both
pytestandpytest-covas specified above in thepyproject.tomlfile.
"},{"location":"tutorials/environment/basic-usage/#conda-environments","title":"Conda environments","text":"$ pip list\nPackage Version Editable project location\n----------- ------- ----------------------------------------------------\ncoverage 7.4.1\niniconfig 2.0.0\npackaging 23.2\npip 23.3.1\npluggy 1.4.0\npytest 8.0.0\npytest-cov 4.1.0\nyourproject 0.1.0 /your/path/to/yourproject\nIf you prefer to use Conda environments with Hatch, you can check out the hatch-conda plugin.
"},{"location":"tutorials/python/manage/","title":"Managing Python distributions","text":"The
pythoncommand group provides a set of commands to manage Python distributions that may be used by other tools.Note
When using environments, manual management is not necessary since by default Hatch will automatically download and manage Python distributions internally when a requested version cannot be found.
"},{"location":"tutorials/python/manage/#location","title":"Location","text":"There are two ways to control where Python distributions are installed. Both methods make it so that each installed distribution is placed in a subdirectory of the configured location named after the distribution.
- The globally configured default directory for Python installations.
- The
-d/--diroption of everypythonsubcommand, which takes precedence over the default directory.
To install a Python distribution, use the
python installcommand. For example:hatch python install 3.12\nThis will:
- Download the
3.12Python distribution - Unpack it into a directory named
3.12within the configured default directory for Python installations - Add the installation to the user PATH
Now its
pythonexecutable can be used by you or other tools.Note
For PATH changes to take effect in the current shell, you will need to restart it.
"},{"location":"tutorials/python/manage/#multiple","title":"Multiple","text":"You can install multiple Python distributions at once by providing multiple distribution names. For example:
hatch python install 3.12 3.11 pypy3.10\nIf you would like to install all available Python distributions that are compatible with your system, use
allas the distribution name:hatch python install all\nTip
The commands for updating and removing also support this functionality.
"},{"location":"tutorials/python/manage/#private","title":"Private","text":"By default, installing Python distributions will add them to the user PATH. To disable this behavior, use the
--privateflag like so:hatch python install 3.12 --private\nThis when combined with the directory option can be used to create private, isolated installations.
"},{"location":"tutorials/python/manage/#listing-distributions","title":"Listing distributions","text":"You can see all of the available and installed Python distributions by using the
python showcommand. For example, if you already installed the3.12distribution you may see something like this:
"},{"location":"tutorials/python/manage/#finding-installations","title":"Finding installations","text":"$ hatch python show\n Installed\n\u250f\u2501\u2501\u2501\u2501\u2501\u2501\u2533\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2513\n\u2503 Name \u2503 Version \u2503\n\u2521\u2501\u2501\u2501\u2501\u2501\u2501\u2547\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2529\n\u2502 3.12 \u2502 3.12.7 \u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n Available\n\u250f\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2533\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2513\n\u2503 Name \u2503 Version \u2503\n\u2521\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2547\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2501\u2529\n\u2502 3.7 \u2502 3.7.9 \u2502\n\u251c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502 3.8 \u2502 3.8.20 \u2502\n\u251c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502 3.9 \u2502 3.9.20 \u2502\n\u251c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502 3.10 \u2502 3.10.15 \u2502\n\u251c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502 3.11 \u2502 3.11.10 \u2502\n\u251c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502 3.13 \u2502 3.13.0 \u2502\n\u251c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502 pypy2.7 \u2502 7.3.15 \u2502\n\u251c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502 pypy3.9 \u2502 7.3.15 \u2502\n\u251c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502 pypy3.10 \u2502 7.3.15 \u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\nThe Python executable of an installed distribution can be found by using the
python findcommand. For example:$ hatch python find 3.12\n/home/.local/share/hatch/pythons/3.12/python/bin/python3\nYou can instead output its parent directory by using the
-p/--parentflag:$ hatch python find 3.12 --parent\n/home/.local/share/hatch/pythons/3.12/python/bin\nThis is useful when other tools do not need to use the executable directly but require knowing the directory containing it.
"},{"location":"tutorials/python/manage/#updates","title":"Updates","text":"To update installed Python distributions, use the
python updatecommand. For example:hatch python update 3.12 3.11 pypy3.10\nWhen there are no updates available for a distribution, a warning will be displayed:
"},{"location":"tutorials/python/manage/#removal","title":"Removal","text":"$ hatch python update 3.12\nThe latest version is already installed: 3.12.3\nTo remove installed Python distributions, use the
python removecommand. For example:
"},{"location":"tutorials/testing/overview/","title":"Testing projects","text":"hatch python remove 3.12 3.11 pypy3.10\nThe
testcommand (by default) uses pytest with select plugins and coverage.py. View the testing configuration for more information.The majority of projects can be fully tested this way without the need for custom environments.
"},{"location":"tutorials/testing/overview/#passing-arguments","title":"Passing arguments","text":"When you run the
testcommand without any arguments,testsis passed as the default argument topytest(this assumes that you have atestsdirectory). For example, the following command invocation:hatch test\nwould be translated roughly to:
pytest tests\nYou can pass arguments to
pytestby appending them to thetestcommand. For example, the following command invocation:hatch test -vv tests/test_foo.py::test_bar\nwould be translated roughly to:
pytest -vv tests/test_foo.py::test_bar\nYou can force the treatment of arguments as positional by using the
--separator, especially useful when built-in flags of thetestcommand conflict with those ofpytest, such as the--helpflag. For example, the following command invocation:hatch test -r -- -r fE -- tests\nwould be translated roughly to:
pytest -r fE -- tests\nNote
It's important to ensure that
"},{"location":"tutorials/testing/overview/#environment-selection","title":"Environment selection","text":""},{"location":"tutorials/testing/overview/#single-environment","title":"Single environment","text":"pytestreceives an argument instructing what to run/where to locate tests. It's default behavior is.meaning that it will exhaustively search for tests in the current directory. This can not just be slow but also lead to unexpected behavior.If no environment options are selected, the
testcommand will only run tests in the first defined environment that either already exists or is compatible. Additionally, the checking order will prioritize environments that define a version of Python that matches the interpreter that Hatch is running on.For example, if you overrode the default matrix as follows:
pyproject.toml hatch.toml[[tool.hatch.envs.hatch-test.matrix]]\npython = [\"3.12\", \"3.11\"]\n\n[[tool.hatch.envs.hatch-test.matrix]]\npython = [\"3.11\"]\nfeature = [\"foo\", \"bar\"]\n[[envs.hatch-test.matrix]]\npython = [\"3.12\", \"3.11\"]\n\n[[envs.hatch-test.matrix]]\npython = [\"3.11\"]\nfeature = [\"foo\", \"bar\"]\nthe expanded environments would normally be:
hatch-test.py3.12\nhatch-test.py3.11\nhatch-test.py3.11-foo\nhatch-test.py3.11-bar\nIf you install Hatch on Python 3.11, the checking order would be:
hatch-test.py3.11\nhatch-test.py3.11-foo\nhatch-test.py3.11-bar\nhatch-test.py3.12\nNote
If you installed Hatch with an official installer or are using one of the standalone binaries, the version of Python that Hatch runs on is out of your control. If you are relying on the single environment resolution behavior, consider explicitly selecting environments based on the Python version instead.
"},{"location":"tutorials/testing/overview/#all-environments","title":"All environments","text":"You can run tests in all compatible environments by using the
pyproject.toml hatch.toml--allflag. For example, say you defined the matrix and overrides as follows:[[tool.hatch.envs.hatch-test.matrix]]\npython = [\"3.12\", \"3.11\"]\nfeature = [\"foo\", \"bar\"]\n\n[tool.hatch.envs.hatch-test.overrides]\nmatrix.feature.platforms = [\n { value = \"linux\", if = [\"foo\", \"bar\"] },\n { value = \"windows\", if = [\"foo\"] },\n { value = \"macos\", if = [\"bar\"] },\n]\n[[envs.hatch-test.matrix]]\npython = [\"3.12\", \"3.11\"]\nfeature = [\"foo\", \"bar\"]\n\n[envs.hatch-test.overrides]\nmatrix.feature.platforms = [\n { value = \"linux\", if = [\"foo\", \"bar\"] },\n { value = \"windows\", if = [\"foo\"] },\n { value = \"macos\", if = [\"bar\"] },\n]\nThe following table shows the environments in which tests would be run:
Environment Linux Windows macOShatch-test.py3.12-foohatch-test.py3.12-barhatch-test.py3.11-foohatch-test.py3.11-bar"},{"location":"tutorials/testing/overview/#specific-environments","title":"Specific environments","text":"You can select subsets of environments by using the
--include/-iand--exclude/-xoptions. These options may be used to include or exclude certain matrix variables, optionally followed by specific comma-separated values, and may be selected multiple times.For example, say you defined the matrix as follows:
pyproject.toml hatch.toml[[tool.hatch.envs.hatch-test.matrix]]\npython = [\"3.12\", \"3.11\"]\nfeature = [\"foo\", \"bar\", \"baz\"]\n[[envs.hatch-test.matrix]]\npython = [\"3.12\", \"3.11\"]\nfeature = [\"foo\", \"bar\", \"baz\"]\nIf you wanted to run tests in all environments that have Python 3.12 and either the
fooorbarfeature, you could use the following command invocation:hatch test -i python=3.12 -i feature=foo,bar\nAlternatively, we could exclude the
bazfeature to achieve the same result:hatch test -i python=3.12 -x feature=baz\nTip
Since selecting the version of Python is a common use case, you can use the
--python/-pyoption as a shorthand. For example, the previous commands could have been written as:
"},{"location":"tutorials/testing/overview/#measuring-code-coverage","title":"Measuring code coverage","text":"hatch test -py 3.12 -i feature=foo,bar\nhatch test -py 3.12 -x feature=baz\nYou can enable code coverage by using the
--coverflag. For example, the following command invocation:hatch test --cover\nwould be translated roughly to:
coverage run -m pytest tests\nAfter tests run in all of the selected environments, the coverage data is combined and a report is shown. The
--cover-quietflag can be used to suppress the report and implicitly enables the--coverflag:hatch test --cover-quiet\nNote
Coverage data files are generated at the root of the project. Be sure to exclude them from version control with the following glob-style pattern:
"},{"location":"tutorials/testing/overview/#retry-failed-tests","title":"Retry failed tests","text":".coverage*\nYou can retry failed tests with the
--retriesoption:hatch test --retries 2\nIf a test fails every time and the number of retries is set to
2, the test will be run a total of three times.You can also set the number of seconds to wait between retries with the
--retry-delayoption:
"},{"location":"tutorials/testing/overview/#parallelize-test-execution","title":"Parallelize test execution","text":"hatch test --retries 2 --retry-delay 1\nYou can parallelize test execution with the
--parallel/-pflag:hatch test --parallel\nThis distributes tests within an environment across multiple workers. The number of workers corresponds to the number of logical rather than physical CPUs that are available.
"},{"location":"tutorials/testing/overview/#randomize-test-order","title":"Randomize test order","text":"You can randomize the order of tests with the
--randomize/-rflag:
"},{"location":"blog/archive/2024/","title":"2024","text":""},{"location":"blog/archive/2023/","title":"2023","text":""},{"location":"blog/archive/2022/","title":"2022","text":""},{"location":"blog/category/release/","title":"Release","text":""}]} \ No newline at end of file diff --git a/1.13/sitemap.xml b/1.13/sitemap.xml new file mode 100644 index 000000000..d4ab5d2c4 --- /dev/null +++ b/1.13/sitemap.xml @@ -0,0 +1,307 @@ + +hatch test --randomize\n+ \ No newline at end of file diff --git a/1.13/sitemap.xml.gz b/1.13/sitemap.xml.gz new file mode 100644 index 000000000..12d27dd07 Binary files /dev/null and b/1.13/sitemap.xml.gz differ diff --git a/1.13/tutorials/environment/basic-usage/index.html b/1.13/tutorials/environment/basic-usage/index.html new file mode 100644 index 000000000..16e2453f4 --- /dev/null +++ b/1.13/tutorials/environment/basic-usage/index.html @@ -0,0 +1,75 @@ ++ +https://hatch.pypa.io/1.13/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/build/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/environment/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/install/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/intro/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/next-steps/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/publish/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/version/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/why/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/blog/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/blog/2024/05/02/hatch-v1100/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/blog/2022/10/08/hatch-v160/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/blog/2023/12/11/hatch-v180/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/blog/2023/12/18/hatch-v190/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/cli/about/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/cli/reference/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/community/contributing/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/community/highlights/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/community/users/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/config/build/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/config/context/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/config/dependency/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/config/hatch/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/config/metadata/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/config/project-templates/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/config/environment/advanced/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/config/environment/overview/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/config/internal/static-analysis/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/config/internal/testing/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/history/hatch/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/history/hatchling/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/how-to/config/dynamic-metadata/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/how-to/environment/dependency-resolution/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/how-to/environment/select-installer/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/how-to/integrate/vscode/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/how-to/meta/report-issues/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/how-to/plugins/testing-builds/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/how-to/publish/auth/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/how-to/publish/repo/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/how-to/python/custom/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/how-to/run/python-scripts/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/how-to/static-analysis/behavior/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/meta/authors/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/meta/faq/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/plugins/about/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/plugins/utilities/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/plugins/build-hook/custom/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/plugins/build-hook/reference/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/plugins/build-hook/version/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/plugins/builder/binary/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/plugins/builder/custom/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/plugins/builder/reference/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/plugins/builder/sdist/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/plugins/builder/wheel/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/plugins/environment/reference/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/plugins/environment/virtual/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/plugins/environment-collector/custom/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/plugins/environment-collector/default/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/plugins/environment-collector/reference/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/plugins/metadata-hook/custom/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/plugins/metadata-hook/reference/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/plugins/publisher/package-index/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/plugins/publisher/reference/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/plugins/version-scheme/reference/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/plugins/version-scheme/standard/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/plugins/version-source/code/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/plugins/version-source/env/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/plugins/version-source/reference/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/plugins/version-source/regex/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/tutorials/environment/basic-usage/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/tutorials/python/manage/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/tutorials/testing/overview/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/blog/archive/2024/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/blog/archive/2023/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/blog/archive/2022/ +2020-02-02 ++ +https://hatch.pypa.io/1.13/blog/category/release/ +2020-02-02 +Managing environments - Hatch Managing environments¶
Hatch environments are isolated workspaces that can be used for project tasks including running tests, building documentation and running code formatters and linters.
The default environment¶
When you start using Hatch, you can create the
defaultenvironment. To do this use theenv createcommand:hatch env create +This will not only create will the
defaultenvironment for you to work in but will also install your project in dev mode in thisdefaultenvironment.Tip
You never need to manually create environments as spawning a shell or running commands within one will automatically trigger creation.
Using the default environment¶
Hatch will always use the
defaultenvironment if an environment is not chosen explicitly when running a command.For instance, the following shows how to get version information for the Python in use.
$ hatch run python -V +Python 3.12.1 +Configure the default environment¶
You can customize the tools that are installed into the
defaultenvironment by adding a table calledtool.hatch.envs.defaultto yourpyproject.tomlfile. Below is an example of adding the dependenciespydanticandnumpyto thedefaultenvironment.[tool.hatch.envs.default] +dependencies = [ + "pydantic", + "numpy", +] +[envs.default] +dependencies = [ + "pydantic", + "numpy", +] +You can declare versions for your dependencies as well within this configuration.
[tool.hatch.envs.default] +dependencies = [ + "pydantic>=2.0", + "numpy", +] +[envs.default] +dependencies = [ + "pydantic>=2.0", + "numpy", +] +Create custom environment¶
You can create custom environments in Hatch by adding a section to your
pyproject.tomlfile[tool.hatch.envs.<ENV_NAME>]. Below you define an environment calledtestand you add thepytestandpytest-covdependencies to that environment's configuration.[tool.hatch.envs.test] +dependencies = [ + "pytest", + "pytest-cov" +] +[envs.test] +dependencies = [ + "pytest", + "pytest-cov" +] +The first time that you call the test environment, Hatch will:
- Create the environment
- Install your project into that environment in dev mode (by default) along with its dependencies.
- Install the environment's dependencies
Run commands within a specific environment¶
Hatch offers a unique environment feature that allows you run a specific command within a specific environment rather than needing to activate the environment as you would using a tool such as Conda or venv.
For instance, if you define an environment called
testthat contains the dependencies from the previous section, you can run thepytestcommand from thetestenvironment using the syntax:hatch run <ENV_NAME>:command +To access the
testenvironment and runpytest, you can run:$ hatch run test:pytest +============================== test session starts =============================== +platform darwin -- Python 3.12.1, pytest-7.4.4, pluggy-1.3.0 +rootdir: /your/path/to/yourproject +collected 0 items +Note
test:pytestrepresents the name of the environment to call (test) and the command to run (pytest).View current environments¶
Above you defined and created a new test environment in your
pyproject.tomlfile. You can now use theenv showcommand to see both the currently created environments and the dependencies in each environment.$ hatch env show + Standalone +┏━━━━━━━━━┳━━━━━━━━━┳━━━━━━━━━━━━━━┓ +┃ Name ┃ Type ┃ Dependencies ┃ +┡━━━━━━━━━╇━━━━━━━━━╇━━━━━━━━━━━━━━┩ +│ default │ virtual │ │ +├─────────┼─────────┼──────────────┤ +│ test │ virtual │ pytest │ +│ │ │ pytest-cov │ +└─────────┴─────────┴──────────────┘ +Note
The output may have more columns depending on your environment configuration.
Locating environments¶
To see where your current environment is located you can use the
env findcommand.$ hatch env find test +/your/path/Application Support/hatch/env/virtual/yourproject/twO2iQR3/test +Note
That path is what you would see on macOS but differs for each platform, and is configurable.
Launching a shell within a specific environment¶
If you wish to launch a shell for a specific environment that you have created, like the previous
testenvironment, you can use:hatch -e test shell +Once the environment is active, you can run commands like you would in any Python environment.
Notice below that when running
pip listin the test environment, you can see:- That you package is installed in editable mode.
- That the environment contains both
pytestandpytest-covas specified above in thepyproject.tomlfile.
$ pip list +Package Version Editable project location +----------- ------- ---------------------------------------------------- +coverage 7.4.1 +iniconfig 2.0.0 +packaging 23.2 +pip 23.3.1 +pluggy 1.4.0 +pytest 8.0.0 +pytest-cov 4.1.0 +yourproject 0.1.0 /your/path/to/yourproject +Conda environments¶
If you prefer to use Conda environments with Hatch, you can check out the hatch-conda plugin.
\ No newline at end of file diff --git a/1.13/tutorials/python/manage/index.html b/1.13/tutorials/python/manage/index.html new file mode 100644 index 000000000..6488f0581 --- /dev/null +++ b/1.13/tutorials/python/manage/index.html @@ -0,0 +1,53 @@ +Managing Python distributions - Hatch Managing Python distributions¶
The
pythoncommand group provides a set of commands to manage Python distributions that may be used by other tools.Note
When using environments, manual management is not necessary since by default Hatch will automatically download and manage Python distributions internally when a requested version cannot be found.
Location¶
There are two ways to control where Python distributions are installed. Both methods make it so that each installed distribution is placed in a subdirectory of the configured location named after the distribution.
- The globally configured default directory for Python installations.
- The
-d/--diroption of everypythonsubcommand, which takes precedence over the default directory.
Installation¶
To install a Python distribution, use the
python installcommand. For example:hatch python install 3.12 +This will:
- Download the
3.12Python distribution - Unpack it into a directory named
3.12within the configured default directory for Python installations - Add the installation to the user PATH
Now its
pythonexecutable can be used by you or other tools.Note
For PATH changes to take effect in the current shell, you will need to restart it.
Multiple¶
You can install multiple Python distributions at once by providing multiple distribution names. For example:
hatch python install 3.12 3.11 pypy3.10 +If you would like to install all available Python distributions that are compatible with your system, use
allas the distribution name:hatch python install all +Private¶
By default, installing Python distributions will add them to the user PATH. To disable this behavior, use the
--privateflag like so:hatch python install 3.12 --private +This when combined with the directory option can be used to create private, isolated installations.
Listing distributions¶
You can see all of the available and installed Python distributions by using the
python showcommand. For example, if you already installed the3.12distribution you may see something like this:$ hatch python show + Installed +┏━━━━━━┳━━━━━━━━━┓ +┃ Name ┃ Version ┃ +┡━━━━━━╇━━━━━━━━━┩ +│ 3.12 │ 3.12.7 │ +└──────┴─────────┘ + Available +┏━━━━━━━━━━┳━━━━━━━━━┓ +┃ Name ┃ Version ┃ +┡━━━━━━━━━━╇━━━━━━━━━┩ +│ 3.7 │ 3.7.9 │ +├──────────┼─────────┤ +│ 3.8 │ 3.8.20 │ +├──────────┼─────────┤ +│ 3.9 │ 3.9.20 │ +├──────────┼─────────┤ +│ 3.10 │ 3.10.15 │ +├──────────┼─────────┤ +│ 3.11 │ 3.11.10 │ +├──────────┼─────────┤ +│ 3.13 │ 3.13.0 │ +├──────────┼─────────┤ +│ pypy2.7 │ 7.3.15 │ +├──────────┼─────────┤ +│ pypy3.9 │ 7.3.15 │ +├──────────┼─────────┤ +│ pypy3.10 │ 7.3.15 │ +└──────────┴─────────┘ +Finding installations¶
The Python executable of an installed distribution can be found by using the
python findcommand. For example:$ hatch python find 3.12 +/home/.local/share/hatch/pythons/3.12/python/bin/python3 +You can instead output its parent directory by using the
-p/--parentflag:$ hatch python find 3.12 --parent +/home/.local/share/hatch/pythons/3.12/python/bin +This is useful when other tools do not need to use the executable directly but require knowing the directory containing it.
Updates¶
To update installed Python distributions, use the
python updatecommand. For example:hatch python update 3.12 3.11 pypy3.10 +When there are no updates available for a distribution, a warning will be displayed:
$ hatch python update 3.12 +The latest version is already installed: 3.12.3 +Removal¶
To remove installed Python distributions, use the
python removecommand. For example:hatch python remove 3.12 3.11 pypy3.10 +\ No newline at end of file diff --git a/1.13/tutorials/testing/overview/index.html b/1.13/tutorials/testing/overview/index.html new file mode 100644 index 000000000..066cd7145 --- /dev/null +++ b/1.13/tutorials/testing/overview/index.html @@ -0,0 +1,76 @@ +Testing projects - Hatch Testing projects¶
The
testcommand (by default) uses pytest with select plugins and coverage.py. View the testing configuration for more information.The majority of projects can be fully tested this way without the need for custom environments.
Passing arguments¶
When you run the
testcommand without any arguments,testsis passed as the default argument topytest(this assumes that you have atestsdirectory). For example, the following command invocation:hatch test +would be translated roughly to:
pytest tests +You can pass arguments to
pytestby appending them to thetestcommand. For example, the following command invocation:hatch test -vv tests/test_foo.py::test_bar +would be translated roughly to:
pytest -vv tests/test_foo.py::test_bar +You can force the treatment of arguments as positional by using the
--separator, especially useful when built-in flags of thetestcommand conflict with those ofpytest, such as the--helpflag. For example, the following command invocation:hatch test -r -- -r fE -- tests +would be translated roughly to:
pytest -r fE -- tests +Note
It's important to ensure that
pytestreceives an argument instructing what to run/where to locate tests. It's default behavior is.meaning that it will exhaustively search for tests in the current directory. This can not just be slow but also lead to unexpected behavior.Environment selection¶
Single environment¶
If no environment options are selected, the
testcommand will only run tests in the first defined environment that either already exists or is compatible. Additionally, the checking order will prioritize environments that define a version of Python that matches the interpreter that Hatch is running on.For example, if you overrode the default matrix as follows:
[[tool.hatch.envs.hatch-test.matrix]] +python = ["3.12", "3.11"] + +[[tool.hatch.envs.hatch-test.matrix]] +python = ["3.11"] +feature = ["foo", "bar"] +[[envs.hatch-test.matrix]] +python = ["3.12", "3.11"] + +[[envs.hatch-test.matrix]] +python = ["3.11"] +feature = ["foo", "bar"] +the expanded environments would normally be:
hatch-test.py3.12 +hatch-test.py3.11 +hatch-test.py3.11-foo +hatch-test.py3.11-bar +If you install Hatch on Python 3.11, the checking order would be:
hatch-test.py3.11 +hatch-test.py3.11-foo +hatch-test.py3.11-bar +hatch-test.py3.12 +Note
If you installed Hatch with an official installer or are using one of the standalone binaries, the version of Python that Hatch runs on is out of your control. If you are relying on the single environment resolution behavior, consider explicitly selecting environments based on the Python version instead.
All environments¶
You can run tests in all compatible environments by using the
--allflag. For example, say you defined the matrix and overrides as follows:[[tool.hatch.envs.hatch-test.matrix]] +python = ["3.12", "3.11"] +feature = ["foo", "bar"] + +[tool.hatch.envs.hatch-test.overrides] +matrix.feature.platforms = [ + { value = "linux", if = ["foo", "bar"] }, + { value = "windows", if = ["foo"] }, + { value = "macos", if = ["bar"] }, +] +[[envs.hatch-test.matrix]] +python = ["3.12", "3.11"] +feature = ["foo", "bar"] + +[envs.hatch-test.overrides] +matrix.feature.platforms = [ + { value = "linux", if = ["foo", "bar"] }, + { value = "windows", if = ["foo"] }, + { value = "macos", if = ["bar"] }, +] +The following table shows the environments in which tests would be run:
Environment Linux Windows macOS hatch-test.py3.12-foo
hatch-test.py3.12-barhatch-test.py3.11-foohatch-test.py3.11-barSpecific environments¶
You can select subsets of environments by using the
--include/-iand--exclude/-xoptions. These options may be used to include or exclude certain matrix variables, optionally followed by specific comma-separated values, and may be selected multiple times.For example, say you defined the matrix as follows:
[[tool.hatch.envs.hatch-test.matrix]] +python = ["3.12", "3.11"] +feature = ["foo", "bar", "baz"] +[[envs.hatch-test.matrix]] +python = ["3.12", "3.11"] +feature = ["foo", "bar", "baz"] +If you wanted to run tests in all environments that have Python 3.12 and either the
fooorbarfeature, you could use the following command invocation:hatch test -i python=3.12 -i feature=foo,bar +Alternatively, we could exclude the
bazfeature to achieve the same result:hatch test -i python=3.12 -x feature=baz +Tip
Since selecting the version of Python is a common use case, you can use the
--python/-pyoption as a shorthand. For example, the previous commands could have been written as:hatch test -py 3.12 -i feature=foo,bar +hatch test -py 3.12 -x feature=baz +Measuring code coverage¶
You can enable code coverage by using the
--coverflag. For example, the following command invocation:hatch test --cover +would be translated roughly to:
coverage run -m pytest tests +After tests run in all of the selected environments, the coverage data is combined and a report is shown. The
--cover-quietflag can be used to suppress the report and implicitly enables the--coverflag:hatch test --cover-quiet +Note
Coverage data files are generated at the root of the project. Be sure to exclude them from version control with the following glob-style pattern:
.coverage* +Retry failed tests¶
You can retry failed tests with the
--retriesoption:hatch test --retries 2 +If a test fails every time and the number of retries is set to
2, the test will be run a total of three times.You can also set the number of seconds to wait between retries with the
--retry-delayoption:hatch test --retries 2 --retry-delay 1 +Parallelize test execution¶
You can parallelize test execution with the
--parallel/-pflag:hatch test --parallel +This distributes tests within an environment across multiple workers. The number of workers corresponds to the number of logical rather than physical CPUs that are available.
Randomize test order¶
You can randomize the order of tests with the
--randomize/-rflag:hatch test --randomize +\ No newline at end of file diff --git a/1.13/users/index.html b/1.13/users/index.html new file mode 100644 index 000000000..14a0324ea --- /dev/null +++ b/1.13/users/index.html @@ -0,0 +1,15 @@ + + + + + +Redirecting... + + + + + + +Redirecting... + + diff --git a/1.13/version/index.html b/1.13/version/index.html new file mode 100644 index 000000000..caa133f66 --- /dev/null +++ b/1.13/version/index.html @@ -0,0 +1,36 @@ +Versioning - Hatch Versioning¶
Configuration¶
When the version is not statically set, configuration is defined in the
tool.hatch.versiontable. Thesourceoption determines the source to use for retrieving and updating the version. The regex source is used by default.The
regexsource requires an optionpaththat represents a relative path to a file containing the project's version:[tool.hatch.version] +path = "src/hatch_demo/__about__.py" +[version] +path = "src/hatch_demo/__about__.py" +The default pattern looks for a variable named
__version__orVERSIONthat is set to a string containing the version, optionally prefixed with the lowercase letterv.If this doesn't reflect how you store the version, you can define a different regular expression using the
patternoption:[tool.hatch.version] +path = "pkg/__init__.py" +pattern = "BUILD = 'b(?P<version>[^']+)'" +[version] +path = "pkg/__init__.py" +pattern = "BUILD = 'b(?P<version>[^']+)'" +The pattern must have a named group called
versionthat represents the version.Display¶
Invoking the
versioncommand without any arguments will display the current version of the project:$ hatch version +0.0.1 +Updating¶
You can update the version like so:
$ hatch version "0.1.0" +Old: 0.0.1 +New: 0.1.0 +The
schemeoption determines the scheme to use for parsing both the existing and new versions. The standard scheme is used by default, which is based on PEP 440.Rather than setting the version explicitly, you can select the name of a segment used to increment the version:
$ hatch version minor +Old: 0.1.0 +New: 0.2.0 +You can chain multiple segment updates with a comma. For example, if you wanted to release a preview of your project's first major version, you could do:
$ hatch version major,rc +Old: 0.2.0 +New: 1.0.0rc0 +When you want to release the final version, you would do:
$ hatch version release +Old: 1.0.0rc0 +New: 1.0.0 +Supported segments¶
Here are the supported segments and how they would influence an existing version of
1.0.0:Segments New version release1.0.0major2.0.0minor1.1.0micropatchfix1.0.1aalpha1.0.0a0bbeta1.0.0b0crcprepreview1.0.0rc0rrevpost1.0.0.post0dev1.0.0.dev0\ No newline at end of file diff --git a/1.13/why/index.html b/1.13/why/index.html new file mode 100644 index 000000000..69c909182 --- /dev/null +++ b/1.13/why/index.html @@ -0,0 +1,12 @@ +Why Hatch? - Hatch Why Hatch?¶
The high level value proposition of Hatch is that if one adopts all functionality then many other tools become unnecessary since there is support for everything one might require. Further, if one chooses to use only specific features then there are still benefits compared to alternatives.
Build backend¶
Hatchling, the build backend sister project, has many benefits compared to setuptools. Here we only compare setuptools as that is the one most people are familiar with.
- Better defaults: The default behavior for setuptools is often not desirable for the average user.
- For source distributions, setuptools has a custom enumeration of files that get included and excluded by default. Hatchling takes the defaults from your version control system such as Git's
.gitignorefile. - For wheels, setuptools attempts to find every directory that looks like a Python package. This is often undesirable as you might ship files to the end-user unintentionally such as test or tooling directories. Hatchling defaults to very specific inclusion based on the project name and errors if no heuristic is satisfied.
- For source distributions, setuptools has a custom enumeration of files that get included and excluded by default. Hatchling takes the defaults from your version control system such as Git's
- Ease of configurability: Hatchling was designed based on a history of significant challenges when configuring setuptools.
- Hatchling uses the same glob pattern syntax as Git itself for every option which is what most users are familiar with. On the other hand, setuptools uses shell-style glob patterns for source distributions while wheels use a mix of shell-style globs and Python package syntax.
- Configuring what gets included in source distributions requires a separate
MANIFEST.infile. The custom syntax and directives must be learned and it is difficult knowing which options in the main files likesetup.pyinfluence the behavior and under what conditions. For Hatchling, everything gets configured in a single file under dedicated sections for specific targets like[tool.hatch.build.targets.wheel]. - By default, non-Python files are excluded from wheels. Including such files requires usually verbose rules for every nested package directory. Hatchling makes no such distinction between file types and acts more like a general build system one might already be familiar with.
- Editable installations: The default behavior of Hatchling allows for proper static analysis by external tools such as IDEs. With setuptools, you must provide additional configuration which means that by default, for example, you would not get autocompletion in Visual Studio Code. This is marked as a legacy feature and may in fact be removed in future versions of setuptools.
- Reproducibility: Hatchling builds reproducible wheels and source distributions by default. setuptools does not support this for source distributions and there is no guarantee that wheels are reproducible.
- Extensibility: Although it is possible to extend setuptools, the API is quite low level. Hatchling has the concept of plugins that are separated into discrete types and only expose what is necessary, leading to an easier developer experience.
Why not?:
If building extension modules is required then it is recommended that you continue using setuptools, or even other backends that specialize in interfacing with compilers.
Environment management¶
Here we compare to both
toxandnox. At a high level, there are a few common advantages:- Python management: Hatch is able to automatically download Python distributions on the fly when specific versions that environments request cannot be found. The alternatives will raise an error, with the option to ignore unknown distributions.
-
Philosophy: In the alternatives, environments are for the most part treated as executable units where a dependency set is associated with an action. If you are familiar with container ecosystems, this would be like defining a
CMDat the end of a Dockerfile but without the ability to change the action at runtime. This involves significant wasted disk space usually because one often requires slight modifications to the actions and therefore will define entirely different environments inherited from a base config just to perform different logic. Additionally, this can be confusing to users not just configuration-wise but also for execution of the different environments.In Hatch, environments are treated as isolated areas where you can execute arbitrary commands at runtime. For example, you can define a single test environment with named scripts that runs unit vs non-unit tests, each command being potentially very long but named however you wish so you get to control the interface. Since environments are treated as places where work is performed, you can also spawn a shell into any which will execute a subprocess that automatically drops into your shell of choice. Your shell will be configured appropriately like
pythonon PATH being updated and the prompt being changed to reflect the chosen environment. -
Configuration:
noxconfig is defined in Python which often leads to increased verbosity and makes it challenging to onboard folks compared to a standardized format with known behaviors.
- Extensibility:
toxallows for extending most aspects of its functionality however the API is so low-level and attached to internals that creating plugins may be challenging. For example, here is atoxplugin that was migrated to an equivalent Hatch environment collector plugin.noxis configured with Python so for the local project you can do whatever you want, however there is no concept of third-party plugins per se. To achieve that, you must usually use a package that wrapsnoxand use that package's imports instead (example).
Why not?:
If you are using
noxand you wish to migrate, and for some reason you notify sessions, then migration wouldn't be a straight translation but rather you might have to redesign that conditional step.Python management¶
Here we compare Python management to that of pyenv.
- Cross-platform: Hatch allows for the same experience no matter the system whereas
pyenvdoes not support Windows so you must use an entirely different project that tries to emulate the functionality. - No build dependencies: Hatch guarantees that every available distribution is prebuilt whereas the alternative requires one to maintain a precise build environment which differs by platform and potentially Python version. Another benefit to this is extremely fast installations since the distributions are simply downloaded and unpacked.
- Optimized by default: The CPython distributions are built with profile guided optimization and link-time optimization, resulting in a 10-30% performance improvement depending on the workload. These distributions have seen wide adoption throughout the industry and are even used by the build system Bazel.
- Simplicity: Hatch treats Python installations as just another directory that one would add to PATH. It can do this for you or you can manage PATH yourself, even allowing for custom install locations. On the other hand,
pyenvoperates by adding shims which then act as wrappers around the actual underlying binaries. This has many unfortunate side effects:- It is incumbent upon the user to manage which specific Python comes first via the CLI, switch when necessary, and/or have a mental model of which versions are exposed globally and locally per-project. This can become confusing quite quickly. When working with Hatch, your global Python installations are only important insofar as they are on PATH somewhere since environments do not use them directly but rather create virtual environments from them, always using a version that is compatible with your project.
- Configuration is required for each shell to properly set up
pyenvon start, leading to inconsistencies when running processes that do not spawn a shell. - Debugging issues with Python search paths can be extremely difficult, especially for users of software. If you or users have ever ran into an issue where code was being executed that you did not anticipate, the issue is almost always
pyenvinfluencing thepythonon PATH.
Why not?:
Currently, Hatch does not allow for the installation of specific patch release versions but rather only uses minor release granularity that tracks the latest patch release. If specific patch releases are important to you then it is best to use an alternative installation mechanism.
\ No newline at end of file diff --git a/latest/404.html b/latest/404.html index 686290ad2..0a5e595b8 100644 --- a/latest/404.html +++ b/latest/404.html @@ -1 +1 @@ -Hatch 404 - Not found
\ No newline at end of file +Hatch 404 - Not found
\ No newline at end of file diff --git a/latest/blog/2022/10/08/hatch-v160/index.html b/latest/blog/2022/10/08/hatch-v160/index.html index 54a301786..0dd3e5916 100644 --- a/latest/blog/2022/10/08/hatch-v160/index.html +++ b/latest/blog/2022/10/08/hatch-v160/index.html @@ -1,4 +1,4 @@ -Hatch v1.6.0 - Hatch Hatch history¶
All notable changes to Hatch will be documented in this file.
The format is based on Keep a Changelog, and this project adheres to Semantic Versioning.
Unreleased¶
1.12.0 - 2024-05-28¶
Changed:
- The
run/env runandtestcommands now treat inclusion variable options as an intersection rather than a union to allow for specific targeting of environments
Added:
- Add ability to control the source of Python distributions
- Upgrade Ruff to 0.4.5
- Upgrade PyApp to 0.22.0 for binary builds
Fixed:
- The
fmtcommand no longer hides the commands that are being executed - Add default timeout for network requests, useful when installing Python distributions
- Fix syntax highlighting contrast for the
config showcommand
1.11.1 - 2024-05-23¶
Added:
- Add official GitHub Action for installing Hatch
Fixed:
- Fix
terminal.styles.spinnerconfiguration - Fix entry points in the pre-built distributions that binaries use
1.11.0 - 2024-05-14¶
Added:
- Upgrade PyApp to 0.21.1 for binary builds
Fixed:
- On Linux, install the highest compatible Python distribution variant based on CPU architecture rather than assuming recent hardware
1.10.0 - 2024-05-02¶
Changed:
- The
run/env run,fmtandshellcommands now only change the current working directory to the project root if not already inside the project - The
shellcommand now accepts a single argument to specify the environment to enter which overrides the standard choice mechanisms. The arguments determining shell options have been converted to flags.
Added:
- Add
testcommand - The
runcommand can now execute scripts that define inline metadata for dependencies and Python version constraints - The
virtualenvironment type now supports the ability to use UV in place of pip & virtualenv - Add
self reportcommand for submitting pre-populated bug reports to GitHub - The reserved environment used for static analysis is now completely configurable
- Add the following methods to the
environmentinterface for complete control over output during life cycle management:app_status_creation,app_status_pre_installation,app_status_post_installation,app_status_project_installation,app_status_dependency_state_check,app_status_dependency_installation_check,app_status_dependency_synchronization - Add binaries for 32-bit versions of Windows
- Read configuration from any
~/.pypircfile for theindexpublisher - Use the Git user as the default username for new project URL metadata
- Add
HATCH_DEBUGenvironment variable that when enabled will show local variables in the case of unhandled tracebacks - The
env showcommand now outputs data about all internal environments when using the--jsonflag - Upgrade default CPython distributions to 20240415
- Upgrade default PyPy distributions to 7.3.15
- Upgrade Ruff to 0.4.2
- Upgrade PyApp to 0.19.0 for binary builds
- Bump the minimum supported version of Hatchling to 1.24.2
- Bump the minimum supported version of virtualenv to 20.26.1
Fixed:
- Maintain consistent data paths for case insensitive file systems
- When projects derive dependencies from metadata hooks, there is now by default a status indicator for when the hooks are executed for better responsiveness
- Properly support projects with a
pyproject.tomlfile but noprojecttable e.g. applications - Fix the
fmtcommand when automatically installing plugin dependencies - Fix dependency inheritance for the template of the
typesenvironment for new projects - Fix warnings related to tar file extraction on Python 3.12+ when unpacking Python distributions for installation
- De-select Ruff rule
E501for thefmtcommand by default since it conflicts with the formatter - Fix colored output from build targets on the first run (build environment creation status indicator issue)
- Set the
packagingdependency version as>=23.2to avoid its URL validation which can conflict with context formatting - Fix the exit code when there happens to be an unhandled exception
- No longer capture both stdout and stderr streams when parsing metadata payloads from build environments
- Fix the
README.mdfile template for new projects to avoid Markdown linting issues
1.9.7 - 2024-04-24¶
Fixed:
- Limit the maximum version of virtualenv due to a backward incompatible change
- Upgrade PyApp to 0.12.0 for binary builds
1.9.4 - 2024-03-12¶
Fixed:
- Limit the maximum version of Hatchling in anticipation of backward incompatible changes
1.9.3 - 2024-01-25¶
Fixed:
- Fix loading of local plugins to account for newly released versions of a dependency
1.9.2 - 2024-01-21¶
Fixed:
- Fix the default token variable name for publishing to PyPI
1.9.1 - 2023-12-25¶
Fixed:
- Ensure that the
dependency_hashmethod of theenvironmentinterface is called aftersync_dependenciesfor cases where the hash is only known at that point, such as for dependency lockers - Only acknowledge the
HATCH_PYTHON_VARIANT_*environment variables for Python resolution for supported platforms and architectures - Fix Python resolution when there are metadata hooks with unsatisfied dependencies
1.9.0 - 2023-12-19¶
Changed:
- Environments prefixed by
hatch-are now considered internal and used for special purposes such as configuration for static analysis
Added:
- Enable docstring formatting by default for static analysis
- Allow for overriding config of internal environments
- Concretely state the expected API contract for the environment interface methods
findandcheck_compatibility - Upgrade Ruff to 0.1.8
- Bump the minimum supported version of Hatchling to 1.21.0
Fixed:
- Ignore a project's Python requirement for environments where the project is not installed
- When not persisting config for static analysis, properly manage internal settings when Ruff's top level table already exists
- Ignore compatibility checks when environments have already been created, significantly improving performance of environment usage
- Properly allow overriding of the
pathoption for thevirtualenvironment type - Fix nushell activation on non-Windows systems
1.8.1 - 2023-12-14¶
Fixed:
- Fix regression in calling subprocesses with updated PATH
- Fix automatic installation of environment plugins when running as a standalone binary
- Change default location of Python installations
1.8.0 - 2023-12-11¶
Changed:
- Drop support for Python 3.7
- The
get_build_processmethod of theenvironmentinterface has been removed; plugins should use the newrun_buildermethod instead - Remove
pyperclipdependency and the--copyflag of theconfig findcommand - When running the
buildcommand all output from builders is now displayed as-is in real time without the stripping of ANSI codes - Version information (for Hatch itself) is now derived from Git
Added:
- Support Python 3.12
- Add installers and standalone binaries
- Add the ability to manage Python installations
- Add
fmtcommand - The
virtualenvironment type can now automatically download requested versions of Python that are not installed - Add
dependency_hashmethod to theenvironmentinterface - The state of installed dependencies for environments is saved as metadata so if dependency definitions have not changed then no checking is performed, which can be computationally expensive
- The
buildcommand now supports backends other than Hatchling - Allow the use of
featuresfor environments whenskip-installis enabled - The default is now
__token__when prompting for a username for thepublishcommand - Add a new
run_buildermethod to theenvironmentinterface - Bump the minimum supported version of Hatchling to 1.19.0
- Bump the minimum supported version of
clickto 8.0.6
Fixed:
- Fix nushell activation
- Better handling of flat storage directory hierarchies for the
virtualenvironment type - Display useful information when running the
versioncommand outside of a project rather than erroring - Fix the
project metadatacommand by only capturing stdout from the backend - Properly support Google Artifact Registry
- Fix parsing dependencies for environments when warnings are emitted
1.7.0 - 2023-04-03¶
Changed:
- The
src-layoutproject template option is now enabled by default - Non-critical output now goes to stderr
Added:
- Add
tool.hatch.env.requiresconfiguration to automatically install dependencies for environment and environment collector plugins - Add
customenvironment collector - Improve syncing of dependencies provided through Git direct references
- Add
isolated_data_directoryattribute to the environment interface - Increase the timeout for and add retries to the
indexpublisher - Expand home and environment variables in configured cache and data directories
- Improve readability of exceptions
- Update project templates
- Bump the minimum supported version of Hatchling to 1.14.0
Fixed:
- Fix displaying the version with the
versioncommand when the version is static and build dependencies are unmet - Fix build environments for the
virtualenvironment type when storing within a relative path - Work around System Integrity Protection on macOS when running commands
- Allow setuptools metadata migration for projects without
setup.pyifsetup.cfgis present - Handle additional edge cases for setuptools metadata migration
- Support boolean values for the
config setcommand
1.6.3 - 2022-10-24¶
Fixed:
- Fix
versioncommand when the version is dynamic and build dependencies are unmet
1.6.2 - 2022-10-20¶
Fixed:
- Fix getting dynamic metadata from hooks for environments when dependencies are not dynamic
1.6.1 - 2022-10-16¶
Fixed:
- Computing the path to the user's home directory now gracefully falls back to
~when it cannot be determined
1.6.0 - 2022-10-08¶
Changed:
- The
run_shell_commandenvironment interface method now accepts arbitrarysubprocess.Popenkeyword arguments. This is not strictly breaking, but will be utilized in upcoming features. - The internal directory structure for storing
virtualenvironments is now more nested. This is not breaking, but any local environments will be created anew.
Added:
- Add
projectcommand group to view details about the project like PEP 621 metadata - Better support for auto-detection of environments by tools like Visual Studio Code now that the storage directory of
virtualenvironments will be flat if Hatch's configuredvirtualenvironment directory resides somewhere within the project root or if it is set to a.virtualenvsdirectory within the user's home directory - Build environments for the
virtualenvironment type are now cached for improved performance - Add
build_environment_existsmethod to the environment interface for implementations that cache the build environment - Add
pathoption to thevirtualenvironment type - Add
--initialize-authflag to theindexpublisher to allow for the saving of authentication information before publishing - Support Bash on Windows for the
shellcommand - The
setuptoolsmigration script no longer modifies the formatting of existingpyproject.tomlconfiguration - Bump the minimum supported version of Hatchling to 1.11.0
Fixed:
- Environments now respect dynamically defined project dependencies
- The
dep hashand alldep showcommands now respect dynamically defined project dependencies - The
env show,dep hash, and alldep showcommands now honor context formatting - Fix matrix variable inclusion filtering of the
runandenv runcommands when there are multiple possible variables - Build environment compatibility is now checked before use
- Decreasing verbosity now has no affect on output that should always be displayed
- Handle more edge cases in the
setuptoolsmigration script - Environments now respect user defined environment variables for context formatting
- Update the scripts in the generated test environment template for new projects to reflect the documentation
- Allow
extra-dependenciesin environment overrides - Depend on
packagingexplicitly rather than relying on it being a transitive dependency of Hatchling
1.5.0 - 2022-08-28¶
Added:
- The
indexpublisher now recognizes repository-specific options - Add the
--ignore-compatflag to theenv runcommand - Setting the
HATCH_PYTHONenvironment variable toselfwill now force the use of the Python executable Hatch is running on forvirtualenvironment creation
Fixed:
- Fix the
--force-continueflag of theenv runcommand - Handle more edge cases in the
setuptoolsmigration script
1.4.2 - 2022-08-16¶
Fixed:
- Fix check for updating static versions with the
versioncommand when metadata hooks are in use
1.4.1 - 2022-08-13¶
Fixed:
- Fix non-detached inheritance disabling for environments
1.4.0 - 2022-08-06¶
Added:
- The default Python for
virtualenvironments now checks PATH before using the one Hatch is running on - Values for environment
env-varsnow support context formatting - Add
nameoverride for environments to allow for regular expression matching - The
indexpublisher now better supports non-PyPI indices - Add certificate options to the
indexpublisher - Display waiting text when checking dependencies and removing environments
- Display help text the first time the
shellcommand is executed - Update project templates with Python 3.11 and the latest versions of various GitHub Actions
- Add support for Almquist (
ash) shells - Add
hyperlinkas a dependency for better handling of package index URLs - Bump the minimum supported version of
virtualenvto 20.16.2 - Bump the minimum supported version of
tomlkitto 0.11.1
Fixed:
- Acknowledge
extra-dependenciesfor theenv showcommand - Fix locating executables within virtual environments on Debian
- Fix managing the terminal size inside the
shellcommand - Fix default code coverage file omission for the
src-layoutproject template option
1.3.1 - 2022-07-11¶
Fixed:
- Support
-h/--helpflag for theruncommand
1.3.0 - 2022-07-10¶
Changed:
- Rename the default publishing plugin from
pypito the more genericindex
Added:
- Support the absence of
pyproject.tomlfiles, as is the case for apps and non-Python projects - Hide scripts that start with an underscore for the
env showcommand by default - Ignoring the exit codes of commands by prefixing with hyphens now works with entire named scripts
- Add a way to require confirmation for publishing
- Add
--force-continueflag to theenv runcommand - Make tracebacks colorful and less verbose
- When shell configuration has not been defined, attempt to use the current shell based on parent processes before resorting to the defaults
- The shell name
pwshis now an alias forpowershell - Remove
atomicwritesdependency - Relax constraint on
userpathdependency - Bump the minimum supported version of Hatchling to 1.4.1
Fixed:
- Keep environments in sync with the dependencies of the selected features
- Use
utf-8for all files generated for new projects - Escape special characters Git may return in the user name when writing generated files for new projects
- Normalize the package name to lowercase in
setuptoolsmigration script - Fix parsing of source distributions during publishing
1.2.1 - 2022-05-30¶
Fixed:
- Fix handling of top level
data_filesinsetuptoolsmigration script
1.2.0 - 2022-05-22¶
Changed:
- The
enter_shellenvironment plugin method now accepts an additionalargsparameter
Added:
- Allow context string formatting for environment dependencies
- Add environment context string formatting fields
env_name,env_type,matrix,verbosity, andargs - Support overriding the default arguments used to spawn shells on non-Windows systems
- Bump the minimum supported version of Hatchling to 1.3.0
Fixed:
- Improve
setuptoolsmigration script
1.1.2 - 2022-05-20¶
Fixed:
- Bump the minimum supported version of Hatchling to 1.2.0
- Update project metadata to reflect support for Python 3.11
1.1.1 - 2022-05-12¶
Fixed:
- Fix
setuptoolsmigration script for non-Windows systems
1.1.0 - 2022-05-12¶
Changed:
- In order to simplify the implementation of command execution for environment plugins, the
run_shell_commandsmethod has been replaced by the singularrun_shell_command. A newcommand_contextmethod has been added to more easily satisfy complex use cases. - The
finalize_commandenvironment plugin method has been removed in favor of the newly introduced context formatting functionality.
Added:
- Add context formatting functionality i.e. the ability to insert values into configuration like environment variables and command line arguments
- Any verbosity for command execution will now always display headers, even for single environments
- Every executed command is now displayed when running multiple commands or when verbosity is enabled
- Similar to
make, ignore the exit code of executed commands that start with-(a hyphen) - Add ability for the
--initflag of thenewcommand to automatically migratesetuptoolsconfiguration - Update project metadata to reflect the adoption by PyPA and production stability
1.0.0 - 2022-04-28¶
This is the first stable release of Hatch v1, a complete rewrite. Enjoy!
Hatch history¶
All notable changes to Hatch will be documented in this file.
The format is based on Keep a Changelog, and this project adheres to Semantic Versioning.
Unreleased¶
1.13.0 - 2024-10-13¶
Added:
- Support managing Python 3.13 distributions
1.12.0 - 2024-05-28¶
Changed:
- The
run/env runandtestcommands now treat inclusion variable options as an intersection rather than a union to allow for specific targeting of environments
Added:
- Add ability to control the source of Python distributions
- Upgrade Ruff to 0.4.5
- Upgrade PyApp to 0.22.0 for binary builds
Fixed:
- The
fmtcommand no longer hides the commands that are being executed - Add default timeout for network requests, useful when installing Python distributions
- Fix syntax highlighting contrast for the
config showcommand
1.11.1 - 2024-05-23¶
Added:
- Add official GitHub Action for installing Hatch
Fixed:
- Fix
terminal.styles.spinnerconfiguration - Fix entry points in the pre-built distributions that binaries use
1.11.0 - 2024-05-14¶
Added:
- Upgrade PyApp to 0.21.1 for binary builds
Fixed:
- On Linux, install the highest compatible Python distribution variant based on CPU architecture rather than assuming recent hardware
1.10.0 - 2024-05-02¶
Changed:
- The
run/env run,fmtandshellcommands now only change the current working directory to the project root if not already inside the project - The
shellcommand now accepts a single argument to specify the environment to enter which overrides the standard choice mechanisms. The arguments determining shell options have been converted to flags.
Added:
- Add
testcommand - The
runcommand can now execute scripts that define inline metadata for dependencies and Python version constraints - The
virtualenvironment type now supports the ability to use UV in place of pip & virtualenv - Add
self reportcommand for submitting pre-populated bug reports to GitHub - The reserved environment used for static analysis is now completely configurable
- Add the following methods to the
environmentinterface for complete control over output during life cycle management:app_status_creation,app_status_pre_installation,app_status_post_installation,app_status_project_installation,app_status_dependency_state_check,app_status_dependency_installation_check,app_status_dependency_synchronization - Add binaries for 32-bit versions of Windows
- Read configuration from any
~/.pypircfile for theindexpublisher - Use the Git user as the default username for new project URL metadata
- Add
HATCH_DEBUGenvironment variable that when enabled will show local variables in the case of unhandled tracebacks - The
env showcommand now outputs data about all internal environments when using the--jsonflag - Upgrade default CPython distributions to 20240415
- Upgrade default PyPy distributions to 7.3.15
- Upgrade Ruff to 0.4.2
- Upgrade PyApp to 0.19.0 for binary builds
- Bump the minimum supported version of Hatchling to 1.24.2
- Bump the minimum supported version of virtualenv to 20.26.1
Fixed:
- Maintain consistent data paths for case insensitive file systems
- When projects derive dependencies from metadata hooks, there is now by default a status indicator for when the hooks are executed for better responsiveness
- Properly support projects with a
pyproject.tomlfile but noprojecttable e.g. applications - Fix the
fmtcommand when automatically installing plugin dependencies - Fix dependency inheritance for the template of the
typesenvironment for new projects - Fix warnings related to tar file extraction on Python 3.12+ when unpacking Python distributions for installation
- De-select Ruff rule
E501for thefmtcommand by default since it conflicts with the formatter - Fix colored output from build targets on the first run (build environment creation status indicator issue)
- Set the
packagingdependency version as>=23.2to avoid its URL validation which can conflict with context formatting - Fix the exit code when there happens to be an unhandled exception
- No longer capture both stdout and stderr streams when parsing metadata payloads from build environments
- Fix the
README.mdfile template for new projects to avoid Markdown linting issues
1.9.7 - 2024-04-24¶
Fixed:
- Limit the maximum version of virtualenv due to a backward incompatible change
- Upgrade PyApp to 0.12.0 for binary builds
1.9.4 - 2024-03-12¶
Fixed:
- Limit the maximum version of Hatchling in anticipation of backward incompatible changes
1.9.3 - 2024-01-25¶
Fixed:
- Fix loading of local plugins to account for newly released versions of a dependency
1.9.2 - 2024-01-21¶
Fixed:
- Fix the default token variable name for publishing to PyPI
1.9.1 - 2023-12-25¶
Fixed:
- Ensure that the
dependency_hashmethod of theenvironmentinterface is called aftersync_dependenciesfor cases where the hash is only known at that point, such as for dependency lockers - Only acknowledge the
HATCH_PYTHON_VARIANT_*environment variables for Python resolution for supported platforms and architectures - Fix Python resolution when there are metadata hooks with unsatisfied dependencies
1.9.0 - 2023-12-19¶
Changed:
- Environments prefixed by
hatch-are now considered internal and used for special purposes such as configuration for static analysis
Added:
- Enable docstring formatting by default for static analysis
- Allow for overriding config of internal environments
- Concretely state the expected API contract for the environment interface methods
findandcheck_compatibility - Upgrade Ruff to 0.1.8
- Bump the minimum supported version of Hatchling to 1.21.0
Fixed:
- Ignore a project's Python requirement for environments where the project is not installed
- When not persisting config for static analysis, properly manage internal settings when Ruff's top level table already exists
- Ignore compatibility checks when environments have already been created, significantly improving performance of environment usage
- Properly allow overriding of the
pathoption for thevirtualenvironment type - Fix nushell activation on non-Windows systems
1.8.1 - 2023-12-14¶
Fixed:
- Fix regression in calling subprocesses with updated PATH
- Fix automatic installation of environment plugins when running as a standalone binary
- Change default location of Python installations
1.8.0 - 2023-12-11¶
Changed:
- Drop support for Python 3.7
- The
get_build_processmethod of theenvironmentinterface has been removed; plugins should use the newrun_buildermethod instead - Remove
pyperclipdependency and the--copyflag of theconfig findcommand - When running the
buildcommand all output from builders is now displayed as-is in real time without the stripping of ANSI codes - Version information (for Hatch itself) is now derived from Git
Added:
- Support Python 3.12
- Add installers and standalone binaries
- Add the ability to manage Python installations
- Add
fmtcommand - The
virtualenvironment type can now automatically download requested versions of Python that are not installed - Add
dependency_hashmethod to theenvironmentinterface - The state of installed dependencies for environments is saved as metadata so if dependency definitions have not changed then no checking is performed, which can be computationally expensive
- The
buildcommand now supports backends other than Hatchling - Allow the use of
featuresfor environments whenskip-installis enabled - The default is now
__token__when prompting for a username for thepublishcommand - Add a new
run_buildermethod to theenvironmentinterface - Bump the minimum supported version of Hatchling to 1.19.0
- Bump the minimum supported version of
clickto 8.0.6
Fixed:
- Fix nushell activation
- Better handling of flat storage directory hierarchies for the
virtualenvironment type - Display useful information when running the
versioncommand outside of a project rather than erroring - Fix the
project metadatacommand by only capturing stdout from the backend - Properly support Google Artifact Registry
- Fix parsing dependencies for environments when warnings are emitted
1.7.0 - 2023-04-03¶
Changed:
- The
src-layoutproject template option is now enabled by default - Non-critical output now goes to stderr
Added:
- Add
tool.hatch.env.requiresconfiguration to automatically install dependencies for environment and environment collector plugins - Add
customenvironment collector - Improve syncing of dependencies provided through Git direct references
- Add
isolated_data_directoryattribute to the environment interface - Increase the timeout for and add retries to the
indexpublisher - Expand home and environment variables in configured cache and data directories
- Improve readability of exceptions
- Update project templates
- Bump the minimum supported version of Hatchling to 1.14.0
Fixed:
- Fix displaying the version with the
versioncommand when the version is static and build dependencies are unmet - Fix build environments for the
virtualenvironment type when storing within a relative path - Work around System Integrity Protection on macOS when running commands
- Allow setuptools metadata migration for projects without
setup.pyifsetup.cfgis present - Handle additional edge cases for setuptools metadata migration
- Support boolean values for the
config setcommand
1.6.3 - 2022-10-24¶
Fixed:
- Fix
versioncommand when the version is dynamic and build dependencies are unmet
1.6.2 - 2022-10-20¶
Fixed:
- Fix getting dynamic metadata from hooks for environments when dependencies are not dynamic
1.6.1 - 2022-10-16¶
Fixed:
- Computing the path to the user's home directory now gracefully falls back to
~when it cannot be determined
1.6.0 - 2022-10-08¶
Changed:
- The
run_shell_commandenvironment interface method now accepts arbitrarysubprocess.Popenkeyword arguments. This is not strictly breaking, but will be utilized in upcoming features. - The internal directory structure for storing
virtualenvironments is now more nested. This is not breaking, but any local environments will be created anew.
Added:
- Add
projectcommand group to view details about the project like PEP 621 metadata - Better support for auto-detection of environments by tools like Visual Studio Code now that the storage directory of
virtualenvironments will be flat if Hatch's configuredvirtualenvironment directory resides somewhere within the project root or if it is set to a.virtualenvsdirectory within the user's home directory - Build environments for the
virtualenvironment type are now cached for improved performance - Add
build_environment_existsmethod to the environment interface for implementations that cache the build environment - Add
pathoption to thevirtualenvironment type - Add
--initialize-authflag to theindexpublisher to allow for the saving of authentication information before publishing - Support Bash on Windows for the
shellcommand - The
setuptoolsmigration script no longer modifies the formatting of existingpyproject.tomlconfiguration - Bump the minimum supported version of Hatchling to 1.11.0
Fixed:
- Environments now respect dynamically defined project dependencies
- The
dep hashand alldep showcommands now respect dynamically defined project dependencies - The
env show,dep hash, and alldep showcommands now honor context formatting - Fix matrix variable inclusion filtering of the
runandenv runcommands when there are multiple possible variables - Build environment compatibility is now checked before use
- Decreasing verbosity now has no affect on output that should always be displayed
- Handle more edge cases in the
setuptoolsmigration script - Environments now respect user defined environment variables for context formatting
- Update the scripts in the generated test environment template for new projects to reflect the documentation
- Allow
extra-dependenciesin environment overrides - Depend on
packagingexplicitly rather than relying on it being a transitive dependency of Hatchling
1.5.0 - 2022-08-28¶
Added:
- The
indexpublisher now recognizes repository-specific options - Add the
--ignore-compatflag to theenv runcommand - Setting the
HATCH_PYTHONenvironment variable toselfwill now force the use of the Python executable Hatch is running on forvirtualenvironment creation
Fixed:
- Fix the
--force-continueflag of theenv runcommand - Handle more edge cases in the
setuptoolsmigration script
1.4.2 - 2022-08-16¶
Fixed:
- Fix check for updating static versions with the
versioncommand when metadata hooks are in use
1.4.1 - 2022-08-13¶
Fixed:
- Fix non-detached inheritance disabling for environments
1.4.0 - 2022-08-06¶
Added:
- The default Python for
virtualenvironments now checks PATH before using the one Hatch is running on - Values for environment
env-varsnow support context formatting - Add
nameoverride for environments to allow for regular expression matching - The
indexpublisher now better supports non-PyPI indices - Add certificate options to the
indexpublisher - Display waiting text when checking dependencies and removing environments
- Display help text the first time the
shellcommand is executed - Update project templates with Python 3.11 and the latest versions of various GitHub Actions
- Add support for Almquist (
ash) shells - Add
hyperlinkas a dependency for better handling of package index URLs - Bump the minimum supported version of
virtualenvto 20.16.2 - Bump the minimum supported version of
tomlkitto 0.11.1
Fixed:
- Acknowledge
extra-dependenciesfor theenv showcommand - Fix locating executables within virtual environments on Debian
- Fix managing the terminal size inside the
shellcommand - Fix default code coverage file omission for the
src-layoutproject template option
1.3.1 - 2022-07-11¶
Fixed:
- Support
-h/--helpflag for theruncommand
1.3.0 - 2022-07-10¶
Changed:
- Rename the default publishing plugin from
pypito the more genericindex
Added:
- Support the absence of
pyproject.tomlfiles, as is the case for apps and non-Python projects - Hide scripts that start with an underscore for the
env showcommand by default - Ignoring the exit codes of commands by prefixing with hyphens now works with entire named scripts
- Add a way to require confirmation for publishing
- Add
--force-continueflag to theenv runcommand - Make tracebacks colorful and less verbose
- When shell configuration has not been defined, attempt to use the current shell based on parent processes before resorting to the defaults
- The shell name
pwshis now an alias forpowershell - Remove
atomicwritesdependency - Relax constraint on
userpathdependency - Bump the minimum supported version of Hatchling to 1.4.1
Fixed:
- Keep environments in sync with the dependencies of the selected features
- Use
utf-8for all files generated for new projects - Escape special characters Git may return in the user name when writing generated files for new projects
- Normalize the package name to lowercase in
setuptoolsmigration script - Fix parsing of source distributions during publishing
1.2.1 - 2022-05-30¶
Fixed:
- Fix handling of top level
data_filesinsetuptoolsmigration script
1.2.0 - 2022-05-22¶
Changed:
- The
enter_shellenvironment plugin method now accepts an additionalargsparameter
Added:
- Allow context string formatting for environment dependencies
- Add environment context string formatting fields
env_name,env_type,matrix,verbosity, andargs - Support overriding the default arguments used to spawn shells on non-Windows systems
- Bump the minimum supported version of Hatchling to 1.3.0
Fixed:
- Improve
setuptoolsmigration script
1.1.2 - 2022-05-20¶
Fixed:
- Bump the minimum supported version of Hatchling to 1.2.0
- Update project metadata to reflect support for Python 3.11
1.1.1 - 2022-05-12¶
Fixed:
- Fix
setuptoolsmigration script for non-Windows systems
1.1.0 - 2022-05-12¶
Changed:
- In order to simplify the implementation of command execution for environment plugins, the
run_shell_commandsmethod has been replaced by the singularrun_shell_command. A newcommand_contextmethod has been added to more easily satisfy complex use cases. - The
finalize_commandenvironment plugin method has been removed in favor of the newly introduced context formatting functionality.
Added:
- Add context formatting functionality i.e. the ability to insert values into configuration like environment variables and command line arguments
- Any verbosity for command execution will now always display headers, even for single environments
- Every executed command is now displayed when running multiple commands or when verbosity is enabled
- Similar to
make, ignore the exit code of executed commands that start with-(a hyphen) - Add ability for the
--initflag of thenewcommand to automatically migratesetuptoolsconfiguration - Update project metadata to reflect the adoption by PyPA and production stability
1.0.0 - 2022-04-28¶
This is the first stable release of Hatch v1, a complete rewrite. Enjoy!
\ No newline at end of file diff --git a/latest/history/hatchling/index.html b/latest/history/hatchling/index.html index dfdbaffb9..6a5281f85 100644 --- a/latest/history/hatchling/index.html +++ b/latest/history/hatchling/index.html @@ -1,4 +1,4 @@ -Hatchling history - Hatch Hatchling history¶
All notable changes to Hatchling will be documented in this file.
The format is based on Keep a Changelog, and this project adheres to Semantic Versioning.
Unreleased¶
Fixed:
- Ignore
manylinux/musllinuxtags for thewheeltarget artifact name when enabling theinfer_tagbuild data
1.24.2 - 2024-04-22¶
Fixed:
- Add
.venvto the list of directories that cannot be traversed - Output from the core Application utility now writes to stderr
1.24.1 - 2024-04-18¶
Fixed:
- Maintain file permissions for
shared-scriptsoption/shared_scriptsbuild data of thewheeltarget
1.24.0 - 2024-04-16¶
Added:
- Add
shared_dataandshared_scriptsbuild data for thewheeltarget
1.23.0 - 2024-04-14¶
Added:
- Add
shared-scriptsoption for thewheeltarget
Fixed:
- Support recursive optional dependencies
- Set the
packagingdependency version as>=23.2to avoid its URL validation which can conflict with context formatting
1.22.5 - 2024-04-04¶
Fixed:
- Fix reading metadata from source distributions when fields are dynamic but not part of core metadata like entry points
1.22.4 - 2024-03-23¶
Fixed:
- Only read source distribution metadata for fields that are explicitly defined as dynamic
1.22.3 - 2024-03-19¶
Fixed:
- Fix the
custombuild hook when using dynamic dependencies
1.22.2 - 2024-03-16¶
Fixed:
- Fix regression when loading metadata from source distributions
- Fix metadata hooks when building wheels from source distributions
1.22.1 - 2024-03-16¶
Fixed:
- Update the default version of core metadata to 2.3
1.22.0 - 2024-03-16¶
Deprecated:
- The
appbuild target has been renamed tobinaryto reduce ambiguity with the name of an upcoming feature. The former name will still be usable for several minor releases.
Added:
- Metadata for the
wheeltarget now defaults to thePKG-INFOmetadata within source distributions - Add
dependenciesmethod to the build hook interface so that hooks can themselves dynamically define dependencies - Update the default version of core metadata to 2.2
- Update SPDX license information to version 3.23
- Improve error message for when the default heuristics for wheel file inclusion fail
Fixed:
- Properly support core metadata version 2.2
- Remove
editablesas a direct dependency - Fix default wheel tag when the supported Python version declaration is strict
- Load VCS ignore patterns first so that whitelisted patterns can be excluded by project configuration
- Don't consider VCS ignore files that are outside of the VCS boundary
- The
sdistbuild target now gracefully ignores UNIX socket files - Begin ignoring certain files ubiquitously, like
.DS_Storeon macOS
1.21.1 - 2024-01-25¶
Fixed:
- Fix loading of local plugins to account for newly released versions of a dependency
1.21.0 - 2023-12-18¶
Added:
- Add
parentcontext modifier for path fields
1.20.0 - 2023-12-13¶
Added:
- Add
bypass-selectionoption to thewheelbuild target to allow for empty (metadata-only) wheels
Fixed:
- Fix regression in 1.19.1 that allowed
excludeto count toward inclusion selection, thus bypassing the default inclusion selection heuristics - Fix writing optional dependency core metadata in situations where there are multiple environment markers
1.19.1 - 2023-12-12¶
Fixed:
- Add better error message when the
wheelbuild target cannot determine what to ship - Consider forced inclusion patterns and build-time artifacts as file selection since some build hooks generate the entire wheel contents without user configuration
1.19.0 - 2023-12-11¶
Changed:
- An error will now be raised if a force-included path does not exist
- An error will now be raised for the
wheelbuild target if no file selection options are defined
Added:
- Officially support Python 3.12
- Allow using an empty string for the
sourcesoption to add a prefix to distribution paths
Fixed:
- Properly handle non-zero version epoch for the
standardversion scheme - Fix the
wheelbuild target for case insensitive file systems when the project metadata name does not match the directory name on disk - The
appbuild target no longer has suppressed output - Prevent duplicate paths when projects require the
sourcesoption while build hooks overwrite included paths - Properly escape spaces for URI context formatting
1.18.0 - 2023-06-12¶
Changed:
- Drop support for Python 3.7
Added:
- Update the list of directories that are always excluded for builds
1.17.1 - 2023-06-03¶
Fixed:
- Fix dev mode when the project has symlinks and file inclusion is defined with the
packagesoronly-includeoptions - Change the name of generated PTH files for dev mode so they come first lexicographically and therefore load first
1.17.0 - 2023-05-12¶
Added:
- The
appbuild target now embeds the project version in the name of binaries
1.16.1 - 2023-05-11¶
Fixed:
- Fix determining the built executable path for the
appbuild target option when using a local copy of PyApp when there is an explicit target triple set
1.16.0 - 2023-05-11¶
Added:
- Add
appbuild target option to build using a local copy of the PyApp repository
1.15.0 - 2023-05-09¶
Added:
- Add
appbuild target
1.14.1 - 2023-04-23¶
Fixed:
- Fix internal archive root naming for the
sdisttarget whenstrict-namingis disabled to match the file name in order to support the expectation of some frontends
1.14.0 - 2023-04-02¶
Added:
- Add
trove-classifiersas a dependency
Fixed:
- Properly normalize metadata descriptions that contain line breaks
1.13.0 - 2023-02-09¶
Added:
- Update the set of known trove classifiers to version 2023.2.8
1.12.2 - 2023-01-05¶
Fixed:
- Add
macos-max-compatoption to thewheeltarget that is enabled by default to support the latest version 22.0 of thepackaginglibrary
1.12.1 - 2022-12-31¶
Fixed:
- Fix minor regression in the PEP 517/660 function signatures that was discovered by Fedora
1.12.0 - 2022-12-30¶
Added:
- Improve readability of exceptions
- Add
extra_metadatabuild data to thewheeltarget - Retroactively support
License-Expressioncore metadata starting at version 2.1 - Add more type hints
- Update the set of known trove classifiers to version 2022.12.22
- Update SPDX license information to version 3.19
- Store Hatchling's metadata in
pyproject.toml
Fixed:
- Acknowledge the
ARCHFLAGSenvironment variable on macOS for thewheeltarget when build hooks set theinfer_tagbuild data totrue - Fix dependency checking when encountering broken distributions
- Fix the
support-legacyoption for thesdisttarget when using a src-layout project structure - Remove unnecessary encoding declaration in the default template for the
versionbuild hook
1.11.1 - 2022-10-19¶
Fixed:
- Fix default file selection behavior of the
wheeltarget when there is a single top-level module
1.11.0 - 2022-10-08¶
Added:
- Add
envversion source to retrieve the version from an environment variable - Add
validate-bumpoption to thestandardversion scheme
Fixed:
- Use proper CSV formatting for the
RECORDmetadata file of thewheeltarget to avoid warnings during installation bypipif, for example, file names contain commas - Fix installations with pip for build hooks that modify runtime dependencies
- Decreasing verbosity now has no affect on output that should always be displayed
1.10.0 - 2022-09-18¶
Added:
- Add the following to the list of directories that cannot be traversed:
__pypackages__,.hg,.hatch,.tox,.nox - Add deprecated option to allow ambiguous features
Fixed:
- Improve tracking of dynamic metadata
- Fix core metadata for entries in
project.optional-dependenciesthat use direct references
1.9.0 - 2022-09-09¶
Changed:
- File pattern matching now more closely resembles Git's behavior
Added:
- Implement a minimal version of
prepare_metadata_for_build_wheelandprepare_metadata_for_build_editablefor non-frontend tools that only need to inspect a project's metadata - Add
metadatacommand to view PEP 621 project metadata - Improve error messages for SPDX license errors
- Retroactively support
License-Filefor core metadata starting at version 2.1 - Bump the minimum supported version of
pathspecto 0.10.1
Fixed:
- Allow the valid non-SPDX
licensevaluesLicenseRef-Public-DomainandLicenseRef-Proprietary - Show the help text of the CLI when no subcommand is selected
1.8.1 - 2022-08-25¶
Fixed:
- Fix default file inclusion for
wheelbuild targets when both the project name and package directory name are not normalized
1.8.0 - 2022-08-16¶
Added:
- Add
get_known_classifiersmethod to metadata hooks
Fixed:
- Fix check for updating static versions with the
versioncommand when metadata hooks are in use
1.7.1 - 2022-08-13¶
Fixed:
- Fix the value of the
relative_pathattribute of included files, that some build plugins may use, when selecting explicit paths
1.7.0 - 2022-08-12¶
Added:
- Add
require-runtime-featuresoption for builders and build hooks - Check for unknown trove classifiers
- Update SPDX license information to version 3.18
Fixed:
- Add better error message for
wheeltarget dev mode installations that define path rewrites with thesourcesoption - Note the
allow-direct-referencesoption in the relevant error messages
1.6.0 - 2022-07-23¶
Changed:
- When no build targets are specified on the command line, now default to
sdistandwheeltargets rather than what happens to be defined in config - The
codeversion source now only supports files with known extensions - Global build hooks now run before target-specific build hooks to better match expected behavior
Added:
- The
codeversion source now supports loading extension modules - Add
search-pathsoption for thecodeversion source
Fixed:
- Fix removing
sourcesusing an empty string value in the mapping - The
strict-namingoption now also applies to the metadata directory ofwheeltargets
1.5.0 - 2022-07-11¶
Added:
- Support the final draft of PEP 639
- Add
strict-namingoption forsdistandwheeltargets
Fixed:
- Project names are now stored in
sdistandwheeltarget core metadata exactly as defined inpyproject.tomlwithout normalization to allow control of how PyPI displays them
1.4.1 - 2022-07-04¶
Fixed:
- Fix forced inclusion of important files like licenses for
sdisttargets when using the explicit selection options - Don't sort project URL metadata so that the rendered order on PyPI can be controlled
1.4.0 - 2022-07-03¶
Changed:
- The
packagesoption uses the newonly-includeoption to provide targeted inclusion, since that is desired most of the time. You can retain the old behavior by using theincludeandsourcesoptions together.
Added:
- Support PEP 561 type hinting
- Add
versionbuild hook - Add
only-includeoption - The
editableversion ofwheeltargets now respects theforce-includeoption by default - The
force-includeoption now supports path rewriting with thesourcesoption - The
wheeltargetshared-dataandextra-metadataoptions now respect file selection options - The
wheeltarget now auto-detects single module layouts - Improve performance by never entering directories that are guaranteed to be undesirable like
__pycache__rather than excluding individual files within - Update SPDX license information to version 3.17
Fixed:
- Don't write empty entry points file for
wheeltargets if there are no entry points defined - Allow metadata hooks to set the
versionin all cases - Prevent duplicate file entries from inclusion when using the
force-includeoption
1.3.1 - 2022-05-30¶
Fixed:
- Better populate global variables for the
codeversion source
1.3.0 - 2022-05-22¶
Removed:
- Remove unused global
argscontext string formatting field
Added:
- Improve error messages for the
envcontext string formatting field
Fixed:
- Fix
uricontext string formatting modifier on Windows
1.2.0 - 2022-05-20¶
Added:
- Allow context formatting for
project.dependenciesandproject.optional-dependencies
1.1.0 - 2022-05-19¶
Added:
- Add
uriandrealcontext string formatting modifiers for file system paths
1.0.0 - 2022-05-17¶
Changed:
- Drop support for Python 2
Added:
- Improve error messaging for invalid versions
- Update project metadata to reflect support for Python 3.11
0.25.1 - 2022-06-14¶
Fixed:
- Fix support for Windows on Python 2 by removing its support for symlinks
0.25.0 - 2022-05-15¶
Added:
- Add
skip-excluded-dirsbuild option - Allow build data to add additional project dependencies for
wheelandsdistbuild targets - Add
force_include_editablebuild data for thewheelbuild target - Add
build_hooksbuild data - Add support for Mercurial's
.hgignorefiles when using glob syntax - Update project metadata to reflect the adoption by PyPA
Fixed:
- Properly use underscores for the name of
force_includebuild data - No longer greedily skip excluded directories by default
0.24.0 - 2022-04-28¶
This is the initial public release of the Hatchling build system. Support for Python 2 will be dropped in version 1.
Hatchling history¶
All notable changes to Hatchling will be documented in this file.
The format is based on Keep a Changelog, and this project adheres to Semantic Versioning.
Unreleased¶
Fixed:
- Ignore
manylinux/musllinuxtags for thewheeltarget artifact name when enabling theinfer_tagbuild data
1.24.2 - 2024-04-22¶
Fixed:
- Add
.venvto the list of directories that cannot be traversed - Output from the core Application utility now writes to stderr
1.24.1 - 2024-04-18¶
Fixed:
- Maintain file permissions for
shared-scriptsoption/shared_scriptsbuild data of thewheeltarget
1.24.0 - 2024-04-16¶
Added:
- Add
shared_dataandshared_scriptsbuild data for thewheeltarget
1.23.0 - 2024-04-14¶
Added:
- Add
shared-scriptsoption for thewheeltarget
Fixed:
- Support recursive optional dependencies
- Set the
packagingdependency version as>=23.2to avoid its URL validation which can conflict with context formatting
1.22.5 - 2024-04-04¶
Fixed:
- Fix reading metadata from source distributions when fields are dynamic but not part of core metadata like entry points
1.22.4 - 2024-03-23¶
Fixed:
- Only read source distribution metadata for fields that are explicitly defined as dynamic
1.22.3 - 2024-03-19¶
Fixed:
- Fix the
custombuild hook when using dynamic dependencies
1.22.2 - 2024-03-16¶
Fixed:
- Fix regression when loading metadata from source distributions
- Fix metadata hooks when building wheels from source distributions
1.22.1 - 2024-03-16¶
Fixed:
- Update the default version of core metadata to 2.3
1.22.0 - 2024-03-16¶
Deprecated:
- The
appbuild target has been renamed tobinaryto reduce ambiguity with the name of an upcoming feature. The former name will still be usable for several minor releases.
Added:
- Metadata for the
wheeltarget now defaults to thePKG-INFOmetadata within source distributions - Add
dependenciesmethod to the build hook interface so that hooks can themselves dynamically define dependencies - Update the default version of core metadata to 2.2
- Update SPDX license information to version 3.23
- Improve error message for when the default heuristics for wheel file inclusion fail
Fixed:
- Properly support core metadata version 2.2
- Remove
editablesas a direct dependency - Fix default wheel tag when the supported Python version declaration is strict
- Load VCS ignore patterns first so that whitelisted patterns can be excluded by project configuration
- Don't consider VCS ignore files that are outside of the VCS boundary
- The
sdistbuild target now gracefully ignores UNIX socket files - Begin ignoring certain files ubiquitously, like
.DS_Storeon macOS
1.21.1 - 2024-01-25¶
Fixed:
- Fix loading of local plugins to account for newly released versions of a dependency
1.21.0 - 2023-12-18¶
Added:
- Add
parentcontext modifier for path fields
1.20.0 - 2023-12-13¶
Added:
- Add
bypass-selectionoption to thewheelbuild target to allow for empty (metadata-only) wheels
Fixed:
- Fix regression in 1.19.1 that allowed
excludeto count toward inclusion selection, thus bypassing the default inclusion selection heuristics - Fix writing optional dependency core metadata in situations where there are multiple environment markers
1.19.1 - 2023-12-12¶
Fixed:
- Add better error message when the
wheelbuild target cannot determine what to ship - Consider forced inclusion patterns and build-time artifacts as file selection since some build hooks generate the entire wheel contents without user configuration
1.19.0 - 2023-12-11¶
Changed:
- An error will now be raised if a force-included path does not exist
- An error will now be raised for the
wheelbuild target if no file selection options are defined
Added:
- Officially support Python 3.12
- Allow using an empty string for the
sourcesoption to add a prefix to distribution paths
Fixed:
- Properly handle non-zero version epoch for the
standardversion scheme - Fix the
wheelbuild target for case insensitive file systems when the project metadata name does not match the directory name on disk - The
appbuild target no longer has suppressed output - Prevent duplicate paths when projects require the
sourcesoption while build hooks overwrite included paths - Properly escape spaces for URI context formatting
1.18.0 - 2023-06-12¶
Changed:
- Drop support for Python 3.7
Added:
- Update the list of directories that are always excluded for builds
1.17.1 - 2023-06-03¶
Fixed:
- Fix dev mode when the project has symlinks and file inclusion is defined with the
packagesoronly-includeoptions - Change the name of generated PTH files for dev mode so they come first lexicographically and therefore load first
1.17.0 - 2023-05-12¶
Added:
- The
appbuild target now embeds the project version in the name of binaries
1.16.1 - 2023-05-11¶
Fixed:
- Fix determining the built executable path for the
appbuild target option when using a local copy of PyApp when there is an explicit target triple set
1.16.0 - 2023-05-11¶
Added:
- Add
appbuild target option to build using a local copy of the PyApp repository
1.15.0 - 2023-05-09¶
Added:
- Add
appbuild target
1.14.1 - 2023-04-23¶
Fixed:
- Fix internal archive root naming for the
sdisttarget whenstrict-namingis disabled to match the file name in order to support the expectation of some frontends
1.14.0 - 2023-04-02¶
Added:
- Add
trove-classifiersas a dependency
Fixed:
- Properly normalize metadata descriptions that contain line breaks
1.13.0 - 2023-02-09¶
Added:
- Update the set of known trove classifiers to version 2023.2.8
1.12.2 - 2023-01-05¶
Fixed:
- Add
macos-max-compatoption to thewheeltarget that is enabled by default to support the latest version 22.0 of thepackaginglibrary
1.12.1 - 2022-12-31¶
Fixed:
- Fix minor regression in the PEP 517/660 function signatures that was discovered by Fedora
1.12.0 - 2022-12-30¶
Added:
- Improve readability of exceptions
- Add
extra_metadatabuild data to thewheeltarget - Retroactively support
License-Expressioncore metadata starting at version 2.1 - Add more type hints
- Update the set of known trove classifiers to version 2022.12.22
- Update SPDX license information to version 3.19
- Store Hatchling's metadata in
pyproject.toml
Fixed:
- Acknowledge the
ARCHFLAGSenvironment variable on macOS for thewheeltarget when build hooks set theinfer_tagbuild data totrue - Fix dependency checking when encountering broken distributions
- Fix the
support-legacyoption for thesdisttarget when using a src-layout project structure - Remove unnecessary encoding declaration in the default template for the
versionbuild hook
1.11.1 - 2022-10-19¶
Fixed:
- Fix default file selection behavior of the
wheeltarget when there is a single top-level module
1.11.0 - 2022-10-08¶
Added:
- Add
envversion source to retrieve the version from an environment variable - Add
validate-bumpoption to thestandardversion scheme
Fixed:
- Use proper CSV formatting for the
RECORDmetadata file of thewheeltarget to avoid warnings during installation bypipif, for example, file names contain commas - Fix installations with pip for build hooks that modify runtime dependencies
- Decreasing verbosity now has no affect on output that should always be displayed
1.10.0 - 2022-09-18¶
Added:
- Add the following to the list of directories that cannot be traversed:
__pypackages__,.hg,.hatch,.tox,.nox - Add deprecated option to allow ambiguous features
Fixed:
- Improve tracking of dynamic metadata
- Fix core metadata for entries in
project.optional-dependenciesthat use direct references
1.9.0 - 2022-09-09¶
Changed:
- File pattern matching now more closely resembles Git's behavior
Added:
- Implement a minimal version of
prepare_metadata_for_build_wheelandprepare_metadata_for_build_editablefor non-frontend tools that only need to inspect a project's metadata - Add
metadatacommand to view PEP 621 project metadata - Improve error messages for SPDX license errors
- Retroactively support
License-Filefor core metadata starting at version 2.1 - Bump the minimum supported version of
pathspecto 0.10.1
Fixed:
- Allow the valid non-SPDX
licensevaluesLicenseRef-Public-DomainandLicenseRef-Proprietary - Show the help text of the CLI when no subcommand is selected
1.8.1 - 2022-08-25¶
Fixed:
- Fix default file inclusion for
wheelbuild targets when both the project name and package directory name are not normalized
1.8.0 - 2022-08-16¶
Added:
- Add
get_known_classifiersmethod to metadata hooks
Fixed:
- Fix check for updating static versions with the
versioncommand when metadata hooks are in use
1.7.1 - 2022-08-13¶
Fixed:
- Fix the value of the
relative_pathattribute of included files, that some build plugins may use, when selecting explicit paths
1.7.0 - 2022-08-12¶
Added:
- Add
require-runtime-featuresoption for builders and build hooks - Check for unknown trove classifiers
- Update SPDX license information to version 3.18
Fixed:
- Add better error message for
wheeltarget dev mode installations that define path rewrites with thesourcesoption - Note the
allow-direct-referencesoption in the relevant error messages
1.6.0 - 2022-07-23¶
Changed:
- When no build targets are specified on the command line, now default to
sdistandwheeltargets rather than what happens to be defined in config - The
codeversion source now only supports files with known extensions - Global build hooks now run before target-specific build hooks to better match expected behavior
Added:
- The
codeversion source now supports loading extension modules - Add
search-pathsoption for thecodeversion source
Fixed:
- Fix removing
sourcesusing an empty string value in the mapping - The
strict-namingoption now also applies to the metadata directory ofwheeltargets
1.5.0 - 2022-07-11¶
Added:
- Support the final draft of PEP 639
- Add
strict-namingoption forsdistandwheeltargets
Fixed:
- Project names are now stored in
sdistandwheeltarget core metadata exactly as defined inpyproject.tomlwithout normalization to allow control of how PyPI displays them
1.4.1 - 2022-07-04¶
Fixed:
- Fix forced inclusion of important files like licenses for
sdisttargets when using the explicit selection options - Don't sort project URL metadata so that the rendered order on PyPI can be controlled
1.4.0 - 2022-07-03¶
Changed:
- The
packagesoption uses the newonly-includeoption to provide targeted inclusion, since that is desired most of the time. You can retain the old behavior by using theincludeandsourcesoptions together.
Added:
- Support PEP 561 type hinting
- Add
versionbuild hook - Add
only-includeoption - The
editableversion ofwheeltargets now respects theforce-includeoption by default - The
force-includeoption now supports path rewriting with thesourcesoption - The
wheeltargetshared-dataandextra-metadataoptions now respect file selection options - The
wheeltarget now auto-detects single module layouts - Improve performance by never entering directories that are guaranteed to be undesirable like
__pycache__rather than excluding individual files within - Update SPDX license information to version 3.17
Fixed:
- Don't write empty entry points file for
wheeltargets if there are no entry points defined - Allow metadata hooks to set the
versionin all cases - Prevent duplicate file entries from inclusion when using the
force-includeoption
1.3.1 - 2022-05-30¶
Fixed:
- Better populate global variables for the
codeversion source
1.3.0 - 2022-05-22¶
Removed:
- Remove unused global
argscontext string formatting field
Added:
- Improve error messages for the
envcontext string formatting field
Fixed:
- Fix
uricontext string formatting modifier on Windows
1.2.0 - 2022-05-20¶
Added:
- Allow context formatting for
project.dependenciesandproject.optional-dependencies
1.1.0 - 2022-05-19¶
Added:
- Add
uriandrealcontext string formatting modifiers for file system paths
1.0.0 - 2022-05-17¶
Changed:
- Drop support for Python 2
Added:
- Improve error messaging for invalid versions
- Update project metadata to reflect support for Python 3.11
0.25.1 - 2022-06-14¶
Fixed:
- Fix support for Windows on Python 2 by removing its support for symlinks
0.25.0 - 2022-05-15¶
Added:
- Add
skip-excluded-dirsbuild option - Allow build data to add additional project dependencies for
wheelandsdistbuild targets - Add
force_include_editablebuild data for thewheelbuild target - Add
build_hooksbuild data - Add support for Mercurial's
.hgignorefiles when using glob syntax - Update project metadata to reflect the adoption by PyPA
Fixed:
- Properly use underscores for the name of
force_includebuild data - No longer greedily skip excluded directories by default
0.24.0 - 2022-04-28¶
This is the initial public release of the Hatchling build system. Support for Python 2 will be dropped in version 1.
\ No newline at end of file diff --git a/latest/how-to/config/dynamic-metadata/index.html b/latest/how-to/config/dynamic-metadata/index.html index f963e8e94..0b9e94801 100644 --- a/latest/how-to/config/dynamic-metadata/index.html +++ b/latest/how-to/config/dynamic-metadata/index.html @@ -1,4 +1,4 @@ -How to configure custom dynamic metadata - Hatch Installation¶
GitHub Actions¶
- name: Install Hatch uses: pypa/hatch@installRefer to the official action for more information.
Installers¶
- In your browser, download the
.pkgfile: hatch-universal.pkg - Run your downloaded file and follow the on-screen instructions.
- Restart your terminal.
-
To verify that the shell can find and run the
hatchcommand in yourPATH, use the following command.$ hatch --version -1.12.0 +1.13.0
-
Download the file using the
curlcommand. The-ooption specifies the file name that the downloaded package is written to. In this example, the file is written tohatch-universal.pkgin the current directory.curl -Lo hatch-universal.pkg https://github.com/pypa/hatch/releases/latest/download/hatch-universal.pkg -
Run the standard macOS
installerprogram, specifying the downloaded.pkgfile as the source. Use the-pkgparameter to specify the name of the package to install, and the-target /parameter for the drive in which to install the package. The files are installed to/usr/local/hatch, and an entry is created at/etc/paths.d/hatchthat instructs shells to add the/usr/local/hatchdirectory to. You must include sudo on the command to grant write permissions to those folders.sudo installer -pkg ./hatch-universal.pkg -target / -
Restart your terminal.
-
To verify that the shell can find and run the
hatchcommand in yourPATH, use the following command.$ hatch --version -1.12.0 +1.13.0
- In your browser, download one the
.msifiles: - Run your downloaded file and follow the on-screen instructions.
- Restart your terminal.
-
To verify that the shell can find and run the
hatchcommand in yourPATH, use the following command.$ hatch --version -1.12.0 +1.13.0
-
Download and run the installer using the standard Windows
msiexecprogram, specifying one of the.msifiles as the source. Use the/passiveand/iparameters to request an unattended, normal installation.msiexec /passive /i https://github.com/pypa/hatch/releases/latest/download/hatch-x64.msimsiexec /passive /i https://github.com/pypa/hatch/releases/latest/download/hatch-x86.msi -
Restart your terminal.
-
To verify that the shell can find and run the
hatchcommand in yourPATH, use the following command.$ hatch --version -1.12.0 +1.13.0
Standalone binaries¶
After downloading the archive corresponding to your platform and architecture, extract the binary to a directory that is on your PATH and rename to
hatch.pip¶
Hatch is available on PyPI and can be installed with pip.
pip install hatchWarning
This method modifies the Python environment in which you choose to install. Consider instead using pipx to avoid dependency conflicts.
pipx¶
pipx allows for the global installation of Python applications in isolated environments.
pipx install hatchHomebrew¶
See the formula for more details.
brew install hatch diff --git a/latest/intro/index.html b/latest/intro/index.html index 6a7d8a7ab..d06ec9d52 100644 --- a/latest/intro/index.html +++ b/latest/intro/index.html @@ -1,4 +1,4 @@ -Introduction - Hatch Why Hatch?¶
The high level value proposition of Hatch is that if one adopts all functionality then many other tools become unnecessary since there is support for everything one might require. Further, if one chooses to use only specific features then there are still benefits compared to alternatives.
Build backend¶
Hatchling, the build backend sister project, has many benefits compared to setuptools. Here we only compare setuptools as that is the one most people are familiar with.
- Better defaults: The default behavior for setuptools is often not desirable for the average user.
- For source distributions, setuptools has a custom enumeration of files that get included and excluded by default. Hatchling takes the defaults from your version control system such as Git's
.gitignorefile. - For wheels, setuptools attempts to find every directory that looks like a Python package. This is often undesirable as you might ship files to the end-user unintentionally such as test or tooling directories. Hatchling defaults to very specific inclusion based on the project name and errors if no heuristic is satisfied.
- For source distributions, setuptools has a custom enumeration of files that get included and excluded by default. Hatchling takes the defaults from your version control system such as Git's
- Ease of configurability: Hatchling was designed based on a history of significant challenges when configuring setuptools.
- Hatchling uses the same glob pattern syntax as Git itself for every option which is what most users are familiar with. On the other hand, setuptools uses shell-style glob patterns for source distributions while wheels use a mix of shell-style globs and Python package syntax.
- Configuring what gets included in source distributions requires a separate
MANIFEST.infile. The custom syntax and directives must be learned and it is difficult knowing which options in the main files likesetup.pyinfluence the behavior and under what conditions. For Hatchling, everything gets configured in a single file under dedicated sections for specific targets like[tool.hatch.build.targets.wheel]. - By default, non-Python files are excluded from wheels. Including such files requires usually verbose rules for every nested package directory. Hatchling makes no such distinction between file types and acts more like a general build system one might already be familiar with.
- Editable installations: The default behavior of Hatchling allows for proper static analysis by external tools such as IDEs. With setuptools, you must provide additional configuration which means that by default, for example, you would not get autocompletion in Visual Studio Code. This is marked as a legacy feature and may in fact be removed in future versions of setuptools.
- Reproducibility: Hatchling builds reproducible wheels and source distributions by default. setuptools does not support this for source distributions and there is no guarantee that wheels are reproducible.
- Extensibility: Although it is possible to extend setuptools, the API is quite low level. Hatchling has the concept of plugins that are separated into discrete types and only expose what is necessary, leading to an easier developer experience.
Why not?:
If building extension modules is required then it is recommended that you continue using setuptools, or even other backends that specialize in interfacing with compilers.
Environment management¶
Here we compare to both
toxandnox. At a high level, there are a few common advantages:- Python management: Hatch is able to automatically download Python distributions on the fly when specific versions that environments request cannot be found. The alternatives will raise an error, with the option to ignore unknown distributions.
-
Philosophy: In the alternatives, environments are for the most part treated as executable units where a dependency set is associated with an action. If you are familiar with container ecosystems, this would be like defining a
CMDat the end of a Dockerfile but without the ability to change the action at runtime. This involves significant wasted disk space usually because one often requires slight modifications to the actions and therefore will define entirely different environments inherited from a base config just to perform different logic. Additionally, this can be confusing to users not just configuration-wise but also for execution of the different environments.In Hatch, environments are treated as isolated areas where you can execute arbitrary commands at runtime. For example, you can define a single test environment with named scripts that runs unit vs non-unit tests, each command being potentially very long but named however you wish so you get to control the interface. Since environments are treated as places where work is performed, you can also spawn a shell into any which will execute a subprocess that automatically drops into your shell of choice. Your shell will be configured appropriately like
pythonon PATH being updated and the prompt being changed to reflect the chosen environment. -
Configuration:
toxonly supports INI configuration and if one desires putting that in the standardpyproject.tomlfile then it must be a multi-line string containing the INI config which would preclude syntax highlighting. Hatch allows for TOML-based config just like most other tools in the Python ecosystem.noxconfig is defined in Python which often leads to increased verbosity and makes it challenging to onboard folks compared to a standardized format with known behaviors.
- Extensibility:
toxallows for extending most aspects of its functionality however the API is so low-level and attached to internals that creating plugins may be challenging. For example, here is atoxplugin that was migrated to an equivalent Hatch environment collector plugin.noxis configured with Python so for the local project you can do whatever you want, however there is no concept of third-party plugins per se. To achieve that, you must usually use a package that wrapsnoxand use that package's imports instead (example).
Why not?:
If you are using
noxand you wish to migrate, and for some reason you notify sessions, then migration wouldn't be a straight translation but rather you might have to redesign that conditional step.Python management¶
Here we compare Python management to that of pyenv.
- Cross-platform: Hatch allows for the same experience no matter the system whereas
pyenvdoes not support Windows so you must use an entirely different project that tries to emulate the functionality. - No build dependencies: Hatch guarantees that every available distribution is prebuilt whereas the alternative requires one to maintain a precise build environment which differs by platform and potentially Python version. Another benefit to this is extremely fast installations since the distributions are simply downloaded and unpacked.
- Optimized by default: The CPython distributions are built with profile guided optimization and link-time optimization, resulting in a 10-30% performance improvement depending on the workload. These distributions have seen wide adoption throughout the industry and are even used by the build system Bazel.
- Simplicity: Hatch treats Python installations as just another directory that one would add to PATH. It can do this for you or you can manage PATH yourself, even allowing for custom install locations. On the other hand,
pyenvoperates by adding shims which then act as wrappers around the actual underlying binaries. This has many unfortunate side effects:- It is incumbent upon the user to manage which specific Python comes first via the CLI, switch when necessary, and/or have a mental model of which versions are exposed globally and locally per-project. This can become confusing quite quickly. When working with Hatch, your global Python installations are only important insofar as they are on PATH somewhere since environments do not use them directly but rather create virtual environments from them, always using a version that is compatible with your project.
- Configuration is required for each shell to properly set up
pyenvon start, leading to inconsistencies when running processes that do not spawn a shell. - Debugging issues with Python search paths can be extremely difficult, especially for users of software. If you or users have ever ran into an issue where code was being executed that you did not anticipate, the issue is almost always
pyenvinfluencing thepythonon PATH.
Why not?:
Currently, Hatch does not allow for the installation of specific patch release versions but rather only uses minor release granularity that tracks the latest patch release. If specific patch releases are important to you then it is best to use an alternative installation mechanism.
Why Hatch?¶
The high level value proposition of Hatch is that if one adopts all functionality then many other tools become unnecessary since there is support for everything one might require. Further, if one chooses to use only specific features then there are still benefits compared to alternatives.
Build backend¶
Hatchling, the build backend sister project, has many benefits compared to setuptools. Here we only compare setuptools as that is the one most people are familiar with.
- Better defaults: The default behavior for setuptools is often not desirable for the average user.
- For source distributions, setuptools has a custom enumeration of files that get included and excluded by default. Hatchling takes the defaults from your version control system such as Git's
.gitignorefile. - For wheels, setuptools attempts to find every directory that looks like a Python package. This is often undesirable as you might ship files to the end-user unintentionally such as test or tooling directories. Hatchling defaults to very specific inclusion based on the project name and errors if no heuristic is satisfied.
- For source distributions, setuptools has a custom enumeration of files that get included and excluded by default. Hatchling takes the defaults from your version control system such as Git's
- Ease of configurability: Hatchling was designed based on a history of significant challenges when configuring setuptools.
- Hatchling uses the same glob pattern syntax as Git itself for every option which is what most users are familiar with. On the other hand, setuptools uses shell-style glob patterns for source distributions while wheels use a mix of shell-style globs and Python package syntax.
- Configuring what gets included in source distributions requires a separate
MANIFEST.infile. The custom syntax and directives must be learned and it is difficult knowing which options in the main files likesetup.pyinfluence the behavior and under what conditions. For Hatchling, everything gets configured in a single file under dedicated sections for specific targets like[tool.hatch.build.targets.wheel]. - By default, non-Python files are excluded from wheels. Including such files requires usually verbose rules for every nested package directory. Hatchling makes no such distinction between file types and acts more like a general build system one might already be familiar with.
- Editable installations: The default behavior of Hatchling allows for proper static analysis by external tools such as IDEs. With setuptools, you must provide additional configuration which means that by default, for example, you would not get autocompletion in Visual Studio Code. This is marked as a legacy feature and may in fact be removed in future versions of setuptools.
- Reproducibility: Hatchling builds reproducible wheels and source distributions by default. setuptools does not support this for source distributions and there is no guarantee that wheels are reproducible.
- Extensibility: Although it is possible to extend setuptools, the API is quite low level. Hatchling has the concept of plugins that are separated into discrete types and only expose what is necessary, leading to an easier developer experience.
Why not?:
If building extension modules is required then it is recommended that you continue using setuptools, or even other backends that specialize in interfacing with compilers.
Environment management¶
Here we compare to both
toxandnox. At a high level, there are a few common advantages:- Python management: Hatch is able to automatically download Python distributions on the fly when specific versions that environments request cannot be found. The alternatives will raise an error, with the option to ignore unknown distributions.
-
Philosophy: In the alternatives, environments are for the most part treated as executable units where a dependency set is associated with an action. If you are familiar with container ecosystems, this would be like defining a
CMDat the end of a Dockerfile but without the ability to change the action at runtime. This involves significant wasted disk space usually because one often requires slight modifications to the actions and therefore will define entirely different environments inherited from a base config just to perform different logic. Additionally, this can be confusing to users not just configuration-wise but also for execution of the different environments.In Hatch, environments are treated as isolated areas where you can execute arbitrary commands at runtime. For example, you can define a single test environment with named scripts that runs unit vs non-unit tests, each command being potentially very long but named however you wish so you get to control the interface. Since environments are treated as places where work is performed, you can also spawn a shell into any which will execute a subprocess that automatically drops into your shell of choice. Your shell will be configured appropriately like
pythonon PATH being updated and the prompt being changed to reflect the chosen environment. -
Configuration:
noxconfig is defined in Python which often leads to increased verbosity and makes it challenging to onboard folks compared to a standardized format with known behaviors.
- Extensibility:
toxallows for extending most aspects of its functionality however the API is so low-level and attached to internals that creating plugins may be challenging. For example, here is atoxplugin that was migrated to an equivalent Hatch environment collector plugin.noxis configured with Python so for the local project you can do whatever you want, however there is no concept of third-party plugins per se. To achieve that, you must usually use a package that wrapsnoxand use that package's imports instead (example).
Why not?:
If you are using
noxand you wish to migrate, and for some reason you notify sessions, then migration wouldn't be a straight translation but rather you might have to redesign that conditional step.Python management¶
Here we compare Python management to that of pyenv.
- Cross-platform: Hatch allows for the same experience no matter the system whereas
pyenvdoes not support Windows so you must use an entirely different project that tries to emulate the functionality. - No build dependencies: Hatch guarantees that every available distribution is prebuilt whereas the alternative requires one to maintain a precise build environment which differs by platform and potentially Python version. Another benefit to this is extremely fast installations since the distributions are simply downloaded and unpacked.
- Optimized by default: The CPython distributions are built with profile guided optimization and link-time optimization, resulting in a 10-30% performance improvement depending on the workload. These distributions have seen wide adoption throughout the industry and are even used by the build system Bazel.
- Simplicity: Hatch treats Python installations as just another directory that one would add to PATH. It can do this for you or you can manage PATH yourself, even allowing for custom install locations. On the other hand,
pyenvoperates by adding shims which then act as wrappers around the actual underlying binaries. This has many unfortunate side effects:- It is incumbent upon the user to manage which specific Python comes first via the CLI, switch when necessary, and/or have a mental model of which versions are exposed globally and locally per-project. This can become confusing quite quickly. When working with Hatch, your global Python installations are only important insofar as they are on PATH somewhere since environments do not use them directly but rather create virtual environments from them, always using a version that is compatible with your project.
- Configuration is required for each shell to properly set up
pyenvon start, leading to inconsistencies when running processes that do not spawn a shell. - Debugging issues with Python search paths can be extremely difficult, especially for users of software. If you or users have ever ran into an issue where code was being executed that you did not anticipate, the issue is almost always
pyenvinfluencing thepythonon PATH.
Why not?:
Currently, Hatch does not allow for the installation of specific patch release versions but rather only uses minor release granularity that tracks the latest patch release. If specific patch releases are important to you then it is best to use an alternative installation mechanism.
\ No newline at end of file diff --git a/versions.json b/versions.json index 81fb01d5e..7a2a6c79e 100644 --- a/versions.json +++ b/versions.json @@ -5,12 +5,17 @@ "aliases": [] }, { - "version": "1.12", - "title": "1.12", + "version": "1.13", + "title": "1.13", "aliases": [ "latest" ] }, + { + "version": "1.12", + "title": "1.12", + "aliases": [] + }, { "version": "1.11", "title": "1.11",