I recently started experimenting with Poetry for package and dependency management, and I am still getting used to the differences between it and my experience with setuptools. Specifically, I would appreciate help in understanding how to handle the following scenario.
I have a data file that I want to bundle with my package stored in a package subdirectory. Using setup.py I would specify the file and directory names in the setup.py file and then access the file in my code using the pkg_resources API.
What is the equivalent approach using Poetry and pyproject.toml?
Unlike setuptools poetry bundles automatically all files within your package folder into your package, unless you haven't explicit excluded them in your .gitignore or the pyproject.toml.
So after the package is installed, you can access them with pkg_resources.
You could still use setuptools's pkg_resources.
You could also use one of those from Python's own standard library:
https://docs.python.org/3/library/pkgutil.html#pkgutil.get_data
https://docs.python.org/3/library/importlib.html#importlib.resources.read_binary
Related
I have a project (a PowerShell module) that relies upon a NuGet package, whose assemblies are loaded into my module via the Add-Type cmdlet. I would like to install this package via NuGet instead of manually copying it into the correct folder. This would save me from committing it's binaries to source control. Also: when thinking about CI/CD, I'd hate to have them in my repo.
I know I can curate a packages.config file and use nuget install instead. But this command installs the package together with it's dependencies into a separate folder and therefore the framework will (runtime) not find the required dependencies.
I know I could also provide a script that performs the nuget install and then copies the required .dll files into a single folder. But I would have to deal with the fact that the package might have different versions for different target frameworks and I'd need to handle the compatibility. Or maybe the package has other additional required files that I know nothing about.
So here my question: there has got to be a simpler way to do this? Something less ... circuitous and cumbersome?
Using the really easy to follow instructions for building a NuGet package for an assembly with an associated package of sources for the symbol server, found here on David Ebbo's blog "The easy way to publish NuGet packages with sources" I have indeed created a pair of packages: binary and sources.
However, the sources package is incomplete and the reason is that the sources come from two class library .csproj and I used ILMerge to combine the results of the second into the first. (*) So, using the minimal .nuspec described in this post and pointing nuget.exe at the .csproj for the "main" library, the binary package is fine, but of course the sources package only has sources for the "main" library, not also for the library that was ILMerged into the "main" library.
How do I fix this (and get the sources for both projects included in the symbol package but only the binary for the "main" project in the binary package)?
FYI, the actual nuget.exe command line was: nuget pack CommandLineLexing.csproj -Build -Symbols -Properties Configuration=Release.
(*) The reason I'm doing this, in case you're interested, is that the second library is a cut down version of my accumulated "C# utilities" library - you know, a bunch of extension methods and other helpers - cut down so it only has the bare minimum needed for this particular project. And so, since it is cut down, I don't want there to be separate assembly for it which might eventually get confused with the full assembly (having the same name, and not a strong name). So I used ILMerge to put the utilities methods into the main assembly (and also mark them internal).
Not going to be easy I'm afraid.
NuGet symbol packages are simply your regular package, with pdbs, augmented with source files.
Assuming you already know you can get a merged PDB with ILMerge/ILRepack (/debug), that part is probably working file, I'm assuming your issue is that only the source files from the current project gets included.
You could simply post-process your symbol.nupkg (which is a zip), and include the source files from your other (merged) project in the src folder (you can even try that manually).
Though if you run srctool.exe -r MyMergedAssembly.pdb, you'll see different root paths, where usually (for a non-merged project) they all have a common prefix.
It may work, if SymbolSource copes with having multiple path prefixes in your PDB, that I haven't tried.
I also failed to find any documentation irt to their processing of symbol packages. We can assume they use pdbstr.exe tool to update the PDB srcsrv section of the PDB file to redirect the symbol loading to their website, but one can only tell if they support multiple roots by testing it.
If you upload your augmented symbol package to symbolsource, you can download the updated PDB using a URL similar to http://srv.symbolsource.org/pdb/Public/Castle.Core.pdb/4C81FC30DF584853B9869EAB2FA7D9891/Castle.Core.pd_ (then unzip it to a pdb file)
Then you can use both srctool.exe file.pdb and pdbstr.exe -r -s:srcsrv -p:file.pdb to verify their work.
I'm trying to create a Dart backend framework that developers can download as a dependancy and have the basic folder structure, Dart files and such generated for them in their own project. From what I understand, downloading a dependancy package only places files inside the package directory/ies (although, I may be wrong).
To get around this, I believe Dart can be used like a Bash script, and can place files in the project directory automatically through running the package's bin files in the terminal (illustrated in the Running a script in a dependency https://www.dartlang.org/tools/pub/cmd/pub-run.html).
Would this be the best way to achieve the desired result? Or is there an easier way to download a framework as a project template? (I'd also like to place similar scripts for generating controllers and such in the tools directory, and don't know if keeping this framework as a dependancy would be necessary after 'install').
Thank you for reading.
You can use pub global activate some_package to be able to use pub global run some_package:some_script or just some_script to allow to run a script contained in a Dart package without adding it to the dependencies.
I think this is the best way to distribute it.
We are migrating over to using packages and NuGet for managing our dependencies on 3rd party components. This works well when referencing packages from within Visual Studio or building on the build server via msbuild.
However there are a number of files that we would like to access in our build scripts and installers. Previously these would be in source control with a well known path, now as the version of the package that we are consuming changes so the path to the package and hence the files is changing.
Is there a simple way I can get the path to a given package? The best solution I currently have is to search for all packages.config files and extract the package version from them.
Examples of the files that we need to access are
The NUnit console executable from the NUnit.Runners package for running unit tests.
License files from various packages that we redistribute with our installer.
Using the packages.config file is a pretty good solution. NuGet itself uses two approaches:
Reading the package information from the packages.config and using that to resolve to the packages path.
Enumerating all the directories in the packages directory.
You could use NuGet.Core to do either of the above if you do not want to write the code yourself. The classes that can be used are the DefaultPackagePathResolver, the PackageReferenceFile and LocalPackageRepository or SharedPackageRepository.
One problem with the second approach is that sometimes NuGet may occasionally leave behind NuGet packages that are not necessarily referenced by a project. In that case looking at the package directories may give you the incorrect information.
The only other approach I can think of might be to read the project files looking for the assembly references. Although that would not work for a solution level package such as NUnit.Runners.
I would like to use NuGet packages for building packages for core helper libraries which I would like to add as source files into other projects. I want to use source files instead of libraries for several reasons, the main one being that I need them in SharePoint Projects, which is on the one hand much easier to deploy than additional libraries, and on the other hand helps to reduce version conflicts.
I know that I can add the source files as content to NuGet Packages, which would install them with the package. But this won't work together with package restore, and I don't want to have these files checked into source control in all projects.
Is it somehow possible to make a NuGet package which doesn't copy the files to the project, but instead adds file links, which point back to the file in the package folder, to the project? I think this approach would solve my use case.
Thanks
pascal
It is possible to add linked files with the use of PowerShell scripts, for example with this NuGet script: http://www.nuget.org/packages/Baseclass.Contrib.Nuget.Linked/