https://pantsbuild.org/ logo
Join Slack
Powered by
Possibly odd question as I've never published anyt...
# development
w
Possibly odd question as I've never published anything to pypi. Is there anything that might be too meta about using Pants to publish a pants plugin?
c
no not at all
I’ve used pants to publish underpants. Not a pants plugin per-se of course, but…
b
Do we have a 
twine
plugin for publishing?
We should...
c
it is using twine yes
b
Booyah
c
e
If you want to automate this though you probably just want to pants package and use PyPIs new OIDC support / GH action.
w
... Oh... Interesting.
Didn't know that was a thing!
e
Yeah, fixed PEX to do this and deleted my long lived token secrets.
w
e
w
Sweet, thanks John
Another question here, while I can ponder my publishing questions - since PyPi has disabled new project registration this weekend. Is there a way to decouple your code/module structure from the name you publish under? And what I mean by that is in the JS world, the code you import is relative to whatever you choose to publish under. 
import { Dialog } from "@robotpajamas/svelte-headlessui"
I could easily re-publish this to another organization, or access files by 
@robotpajamas/svelte-headlessui/Dialog
So, if I have something like: 
pip install robotpajamas.pants.scie
Does that mean, if I want to import using the same structure, I necessarily need to keep my source files in that same module structure too? Or is there some alias concept I can apply? So like, 
root/src/scie
somehow automagically becomes 
robotpajamas.pants.scie
?
And I know the package name and module structure don't need to be identical (ala 
pantsbuild.pants
imports at 
<http://pants.xyz|pants.xyz>
)
e
Your code is decoupled from the name you publish under as you already called the shot on in your last sentence. I think what you mean to ask has nothing to do with publishing, but layout vs import. That too can be arbitrary iff you use an import hook. Pex does this and adds the 
__pex__.
psuedo-package prefix to all 3rdparty code.
In general you absolutely don't want to do either.
w
Why's that?
e
The former, pantsbuild.pants->pants, setuptools->setuptools,pkg_resources just confuses the hell out of people. The latter is complex magic that ... why would you want to do that?
w
Well, I think I'm referring to the opposite-ish. The source code module structure vs publish structure. So, I WANT the 
pip install abc.xzy.scie
to be how the end user also consumes the plugin. So from the user's perspective, the experience is consistent. I was just mildly hoping to not have to also make my source code structure align to the same tedious namespacing convention.
Having folders for the sake of namespacing only feels very.... Java-y
e
I'd get with the ecosystem if I were you. Fighting convention is exactly that in the long run unless it's deeply important to you.
You could clearly insert leading dirs as a last second packaging step and pray you don't break imports
w
Nah, not super important. Just feels... antiquated. Was hoping there was some semi-official namespacing mechanism. 🤷
e
Nope
w
C'est la vie, I suppose. Thanks John
Open in Slack
PreviousNext
Powered by