You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Should we be a set of packages instead of a single package? #73
This reddit comment is quite pertinent. ! Using sub-packages would allow users to use any small tools the way they want.
However, I'm not sure to understand the subtle difference between module and package. I thought any collection of python files was a package... On my opinion this question is more about the code architecture, isn't it ?
Or is it about providing a lot of little tools instead of few macro functions ?
(I'm sorry if I sound dump, I'm quite a newbie in project development ^^)
I'm inclined to agree with @antoinelpp. I don't really see much of a useful distinction between calling it a module or a package, though I'm happy to be educated on that if I'm just being ignorant.
I do think that structuring it as a number of fairly self-contained sub-modules/sub-packages (following the astropy model again) does make sense, so I'm happy to do that to the extent that it's useful for us.
changed the title [-]Should we be a set of packages instead of a package?[/-][+]Should we be a set of packages instead of a single package?[/+]on Aug 1, 2017
Oh yeah, I did misspeak there. I intended to say that a system of sub-packages for organization would be neat. As it stands, we've got three main branches: analytic functions, atomic data (the two I of which I think could be gathered into a single knowledge about plasmas package for which I lack a name), and then there's simulation which currently seems to be branching into PIC and MHD. Would that be a reasonable set of packages?
I suppose we could also use a schematic for how the package is organized, I'll try to whip something up with graphviz.
Oh yeah, I just noticed this is a duplicate of #51. Sorry, I was in a rush to type down the recent issues raised.
I am a big fan of the Astropy model where there's the core Astropy package with the functionality needed by most plasma physicists and then a long list of affiliated packages with more specialized functionality.
I am wondering if we should keep simulation as a subpackage within the core PlasmaPy package because it would contain functionality that would probably be needed in several specialized packages.
I had to look it up, but it appears that a module is what's contained in a single .py file, while a package is a collection of .py files organized into some hierarchical structure. Learn something new every day!
Perhaps asking how we want to write and structure tests will help clarify
some of this? I find that when I write out my test cases, get a much
stronger feeling for how I should organize things.
Oh...I forgot to say that it is no problem at all to set up new packages through the PlasmaPy organization on GitHub. We already have one set up for PlasmaPy Enhancement Proposals though nothing is yet there.
Activity
antoinetavant commentedon Aug 1, 2017
This reddit comment is quite pertinent. ! Using sub-packages would allow users to use any small tools the way they want.
However, I'm not sure to understand the subtle difference between module and package. I thought any collection of python files was a package... On my opinion this question is more about the code architecture, isn't it ?
Or is it about providing a lot of little tools instead of few macro functions ?
(I'm sorry if I sound dump, I'm quite a newbie in project development ^^)
SolarDrew commentedon Aug 1, 2017
I'm inclined to agree with @antoinelpp. I don't really see much of a useful distinction between calling it a module or a package, though I'm happy to be educated on that if I'm just being ignorant.
I do think that structuring it as a number of fairly self-contained sub-modules/sub-packages (following the astropy model again) does make sense, so I'm happy to do that to the extent that it's useful for us.
[-]Should we be a module instead of a package?[/-][+]Should we be a set of packages instead of a package?[/+][-]Should we be a set of packages instead of a package?[/-][+]Should we be a set of packages instead of a single package?[/+]StanczakDominik commentedon Aug 1, 2017
Oh yeah, I did misspeak there. I intended to say that a system of sub-packages for organization would be neat. As it stands, we've got three main branches: analytic functions, atomic data (the two I of which I think could be gathered into a single
knowledge about plasmaspackage for which I lack a name), and then there'ssimulationwhich currently seems to be branching intoPICandMHD. Would that be a reasonable set of packages?I suppose we could also use a schematic for how the package is organized, I'll try to whip something up with graphviz.
Oh yeah, I just noticed this is a duplicate of #51. Sorry, I was in a rush to type down the recent issues raised.
namurphy commentedon Aug 1, 2017
I am a big fan of the Astropy model where there's the core Astropy package with the functionality needed by most plasma physicists and then a long list of affiliated packages with more specialized functionality.
I am wondering if we should keep
simulationas a subpackage within the core PlasmaPy package because it would contain functionality that would probably be needed in several specialized packages.I had to look it up, but it appears that a module is what's contained in a single
.pyfile, while a package is a collection of.pyfiles organized into some hierarchical structure. Learn something new every day!blalterman commentedon Aug 1, 2017
namurphy commentedon Aug 1, 2017
Oh...I forgot to say that it is no problem at all to set up new packages through the PlasmaPy organization on GitHub. We already have one set up for PlasmaPy Enhancement Proposals though nothing is yet there.